Visual-Studio-error-phantom-System-Drawing-Common

It's a Nuget error. Do a google search for error code "NU1301" to find some clue.

I already know it's a NuGet error. But why is NuGet trying to fetch packages/System.Drawing.Common/4.7.2 when that package isn't even used for a WL8 .NET 8.0 solution in the first place? Can you answer that?

A Google search doesn't tell me why it's looking for a package it doesn't need. Is there something that needs resetting somewhere? The Google search isn't helping.

I'm still stuck.

I suggest going down the path that ScottPlot is the culprit. If you take a look at the scottplot.nuspec file (for both versions 4.1.68 and 4.1.71) you'll see references to System.Drawing.Common version 4.7.2. See if blazing that trail helps.

Perhaps somewhere along the way something got messed up on a package restore (just a guess).

Also, here's a simple small project that uses ScottPlot 4.1.71 via nuget. There's the System.Drawing.Common 4.7.2 reference. Keep in mind that your project will indirectly reference many resources. (And, albeit a long shot, it kind of looks like you had connection problems to nuget.org, but since you were stuck, I suppose for a while, that is not the case continuously. If it is, trying flushing your DNS cache.)

QUOTE:
small project that uses ScottPlot 4.1.71 via nuget. There's the System.Drawing.Common 4.7.2 reference. ... your project will indirectly reference many resources.

What I didn't say, and perhaps I should have, is that I never installed ScottPlot 4.1.71 on my system, so its System.Drawing.Common 4.7.2 dependency was never realized by the NuGet package installer on my workstation. I didn't need to install it because the WL8 installer installed ScottPlot 4.1.71 for me in the WL8 install directory.... But it never told Visual Studio (or NuGet) about it. (Kind of sneaky.) However, I never had this problem until now.

Okay, I see System.Drawing.Common 4.7.2 in the WL8 install directory. So you're saying if I add that reference to my Visual Studio solution (which uses ScottPlot 4.1.71), that should fix this problem. That's an interesting thought.

So ScottPlot 4.1.71 is based on .NET Core 3.1 (and requires System.Drawing.Common 4.7.2) and ScottPlot 5.0 doesn't. Interesting. I do know ScottPlot 5.0 is portable to Linux and similar unix OSes (like the MacOS).

QUOTE:
So you're saying if I add that reference to my Visual Studio solution (which uses ScottPlot 4.1.71), that should fix this problem. That's an interesting thought.

Sorry if I implied that. I meant only to demonstrate that ScottPlot uses System.Drawing.Common 4.7.2, and perhaps that is where to start looking for the problem.

I did add a reference to the System.Drawing.Common 4.7.2 assembly in the WL8 install directory, but that didn't clear the problem. (I've since removed that reference.)

Next I asked the VS NuGet packet manager to install the System.Drawing.Common 4.7.2 assembly into my WL8 solution (which does reference ScottPlot 4.1.71). That action cleared the problem. Now I get version conflict warnings (see below), but it all compiles and works. I'm not sure how to resolve the warnings.

CODE:
There was a conflict between "System.Drawing.Common, Version=4.0.2.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.Drawing.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
    "System.Drawing.Common, Version=4.0.2.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was chosen because it was primary and "System.Drawing.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was not.

That sounds like a pain. In your project, expand the Packages folder. Is ScottPlot in there? If so, use the NuGet Package manager to remove that reference. You already are referencing it in your Assemblies (via a direct DLL reference).

I setup a little test project, and it compiles fine. Here's the layout in VS 2022:



Here is the project file:

CODE:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0-windows</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PlatformTarget>x64</PlatformTarget>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MathNet.Numerics" Version="5.0.0" />
  </ItemGroup>

  <ItemGroup>
    <Reference Include="finantic.InteractiveGraphics">
      <HintPath>..\..\..\..\..\Program Files\Quantacula, LLC\WealthLab 8\finantic.InteractiveGraphics.dll</HintPath>
    </Reference>
    <Reference Include="ScottPlot">
      <HintPath>..\..\..\..\..\Program Files\Quantacula, LLC\WealthLab 8\ScottPlot.dll</HintPath>
    </Reference>
    <Reference Include="ScottPlot.WPF">
      <HintPath>..\..\..\..\..\Program Files\Quantacula, LLC\WealthLab 8\ScottPlot.WPF.dll</HintPath>
    </Reference>
    <Reference Include="WealthLab.Core">
      <HintPath>..\..\..\..\..\Program Files\Quantacula, LLC\WealthLab 8\WealthLab.Core.dll</HintPath>
    </Reference>
    <Reference Include="WealthLab.WPF">
      <HintPath>..\..\..\..\..\Program Files\Quantacula, LLC\WealthLab 8\WealthLab.WPF.dll</HintPath>
    </Reference>
  </ItemGroup>

</Project>

Now, if I go and add ScottPlot 4.1.71 via NuGet, and compile the solution then it spits out the 4.7.2 problem.

Also, check ScreenCard for the same issue.

Why you received the NU1301 error may be related to the above.

QUOTE:
In your project, expand the Packages folder. Is ScottPlot in there?

No, I've never downloaded the ScottPlot project because WL8 installs it already. Here's my solution for WL8 projects in Visual Studio 2022.


However, I do have a NuGet System.Drawing.Common 4.7.2 package installed for WL7 projects under Visual Studio 2019. Are you suggesting that's a problem?

I could uninstall that System.Drawing.Common 4.7.2 package for WL7 projects. I'm not even using WL7 anymore, but I still use WL6 and .NET 4.6.2.

Another idea...

Remove the System.Drawing.Common package and try cleaning local nuget fiolders:
https://learn.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders#clearing-local-folders