winforms
winforms copied to clipboard
Using WinForms Controls provided via NuGet inside the Out-Of-Process Designer without copying them to the build output
Environment
17.10.0 Preview 6.0
.NET version
8.0
Did this work in a previous version of Visual Studio and/or previous .NET release?
.NET Framework
Issue description
I cannot find a way to use WinForms controls inside my plugin project that are provided by the main application without including them in the project build output and therefore also distributing them via dotnet publish
. They are only "compile time" dependencies as they are provided by the main application when the plugin is loaded inside it.
In the .NET Framework, I was able to provide the WinForms controls inside a NuGet package in the ref
folder so that they were not copied to the build output. After wondering why this did not work after migrating to .NET 8, I finally found the Control Library NuGet Package Spec and found out that they need to be distributed inside the lib
folder because the new WinForms Out-Of-Process .NET Designer needs them at "runtime".
This requirement conflicts with the documentation on how to structure plugin projects available here: Create a .NET Core application with plugins, as it says there:
Let's say that there is an app A that has a plugin interface defined in the NuGet package named A.PluginBase. How do you reference the package correctly in your plugin project? [...] To correctly reference the A.PluginBase package, you want to change the <PackageReference> element in the project file to the following:
<PackageReference Include="A.PluginBase" Version="1.0.0">
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
This prevents the A.PluginBase assemblies from being copied to the output directory of your plugin and ensures that your plugin will use A's version of A.PluginBase.
When I use <ExcludeAssets>runtime</ExcludeAssets>
for my winforms control library, the lib
content is not copied to the build output anymore (good), but the WinForms Out-Of-Process .NET Designer is also not working anymore (bad). The controls are listed inside the toolbox, but fail to be instanciated which might be expected by the current architecture.
What is the suggested approach for solving this constellation?
Steps to reproduce
Install any NuGet package that contains UI controls (e.g. ReaLTaiizor) and try to exclude them from the build output while still being able to use them in the Out-Of-Process Designer.
Diagnostics
No response
You could do something like:
<ItemGroup>
<PackageReference Include="SomeNuGetPackage" Version="1.0.0"
Condition="'$(Configuration)'=='Debug'"/>
</ItemGroup>
OR
<ItemGroup>
<PackageReference Include="SomeNuGetPackage" Version="1.0.0">
<Publish>false</Publish>
</PackageReference>
</ItemGroup>
@Olina-Zhang can your team please test this and make sure a workaround is possible?
@elachlan @SteffenSchwaiger, the below workaround working well that the third part control can be copied to the build output, and the exe can launch successfully.
<ItemGroup>
<PackageReference Include="SomeNuGetPackage" Version="1.0.0">
<Publish>false</Publish>
</PackageReference>
</ItemGroup>
And the below workaround will cause the application published failed.
<ItemGroup>
<PackageReference Include="SomeNuGetPackage" Version="1.0.0"
Condition="'$(Configuration)'=='Debug'"/>
</ItemGroup>
Thanks for the workaround. Although this also means that I have to publish the library on every build if I want a directory without the dependency for debugging purposes, right?
I'd say so, yes. I'm not sure how to get around that and the team will need to investigate.
@Shyam-Gupta will take a look