Wow @CoderPM2011, great find! This is fantastic! 🚀

Hi @CoderPM2011 - I'm curious, how are you testing this?

I have a SDK project that I set to target net48 and I'm getting this 😅

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

    <PropertyGroup>
        <OutputType>WinExe</OutputType>
        <TargetFramework>net48</TargetFramework>
        <Nullable>enable</Nullable>
        <UseWindowsForms>true</UseWindowsForms>
        <ImplicitUsings>enable</ImplicitUsings>
        <IsPackable>false</IsPackable>
        <SignAssembly>True</SignAssembly>
        <LangVersion>latest</LangVersion>
        <AssemblyOriginatorKeyFile>../../Key.snk</AssemblyOriginatorKeyFile>
    </PropertyGroup>

    <ItemGroup>
        <ProjectReference Include="..\..\ScottPlot5 Controls\ScottPlot.OpenGL\ScottPlot.OpenGL.csproj" />
        <ProjectReference Include="..\..\ScottPlot5 Controls\ScottPlot.WinForms\ScottPlot.WinForms.csproj" />
        <ProjectReference Include="..\..\ScottPlot5\ScottPlot.csproj" />
    </ItemGroup>

</Project>

namespace Sandbox.WinForms;

static class Program
{
    [STAThread]
    static void Main()
    {
#if NETFRAMEWORK
#else
        ApplicationConfiguration.Initialize();
#endif
        Application.Run(new Form1());
    }
}

Oof, it seems to be failing for me the same way when I try to load any control (including a blank one) from the ScottPlot.WinForms assembly 💀

Hi @CoderPM2011 - I'm curious, how are you testing this?

I first have the ScottPlot.WinForms project generate the Nuget package.
Then in the newly created .Net Framework 4.6.2 project, install the locally generated Nuget package for testing.

Hi @CoderPM2011 - I'm curious, how are you testing this?

I first have the ScottPlot.WinForms project generate the Nuget package. Then in the newly created .Net Framework 4.6.2 project, install the locally generated Nuget package for testing.

Ah, interesting! I've only tested this running from source which may explain why I've had difficulty reaching a solution.

Thanks again for your feedback and this PR! I'm excited to give this a try soon 👍

Ah, interesting! I've only tested this running from source which may explain why I've had difficulty reaching a solution.

I'm guessing that the reason for the failure to work from the source code may be related to multiple target frameworks or whether VS itself is running properly. 🤔

In my repository branch test-#4362.

I tested the pattern directly referenced in the source project.
I found that the multi-target framework does affect the toolbox.
Maybe it has something to do with this dotnet/msbuild#7856 .

If I change ScottPlot.WinForms to only target net462 then I get it working.
Sometimes you encounter an exception. After restarting Visual Studio, try again and it will work normally.

My test result

I found that the multi-target framework does affect the toolbox.

Wow, that was the magic piece of information! I got it working now and will refine the error screen a bit. This is what I'm thinking of having it show when the DLL fails to load:

... but if this is successful after the next release, I'm tempted to use System.Drawing.Graphics to manually draw a title, grid, and axes, and display it as a Bitmap in a PictureBox and I bet most people will have no idea there was a failure! 🚀

I'll merge this now, but note that it has been modified to only show this message if design time mode is detected. The reason is I don't want that message accidentally showing up on client machines of a third party publishes an app using ScottPlot. Instead, we can explore adding a new PR to display a user-facing message (not aimed at developers necessarily) for when the DLL cannot be located.

This is a semi-common issue actually, unrelated to running inside visual studio, because sometimes people build an app but forget to include all those platform specific subfolders (e.g., I once published a WinForms app and omitted the arm folders but someone with one of those new windows arm tablet PCs couldn't load the app)