Home: Please allow extension SDK manifests to light up for Windows Forms also

[jnm2]

The toolbox can automatically display XAML controls from referenced NuGet packages via extension SDK manifests. It would be amazing if the same behavior lit up for Windows Forms projects too:

<?xml version="1.0" encoding="utf-8"?>
<FileList>
  <File Reference="CompanyName.LibraryName.dll">
    <ToolboxItems VSCategory="CompanyName LibraryName (2.1.0-rc)">
      <Item Type="LibraryNamespace.ControlName" />
    </ToolboxItems>
  </File>
</FileList>

This current lack in Visual Studio has been an ongoing issue as my company has migrated from shared projects to NuGet packages for our own internal controls. I eventually came up with a workaround (detailed at https://github.com/NuGet/Home/issues/3509#issuecomment-347621114) which does install tools into the toolbox automatically. It's not perfect but it's a lifesaver. It's a shame that we're forced to use such a dubious workaround though.

NuGet has recently become a popular distribution model for DevExpress's many Windows Forms controls as well. I've gathered that you worked with Telerik on the XAML control distribution model. The NuGet/toolbox work seems to be mostly done. It would make sense to afford the same convenience to DevExpress customers who use Windows Forms.

Would you please consider this?

[PatoBeltran]

@anangaur could you please take a look at this issue?

[anangaur]

/cc: @karann-msft

[ghost]

Are there any updates on this? I've built several controls for Windows Forms and I need to have them automatically added to the Visual Studio Toolbox.

[sansjunk]

Any updates on this? I am looking for this feature as well.

[jnm2]

I'm using Visual Studio 15.8 Preview 4 and I'm not sure what I'm seeing, but the toolbox is behaving very differently! Is work being done in 15.8 to discover Windows Forms toolbox items in package references?

[Misiu]

@karann-msft any news about this feature? It would be awesome to finally be able to share controls via NuGet (and have them in Toolbox).

[mgoertz-msft]

We did add support for WinForms in 15.8 (and fixed a few bugs in 15.9). However, it does not use the manifest but does it the traditional WinForms way showing all IComponent derived controls and using attributes to control the behavior:

Hide Controls
[ToolboxItem(false)]
[DesigntimeVisible(false)]

Category Name
[assembly: AssemblyProduct("My Controls")]

Tooltip Description
[Description(“What my control does”)]

[jnm2]

@mgoertz-msft Even better than the manifest, I think! Thanks! I noticed that no icons are showing up in the toolbox for components discovered this way. Will that be fixed?

[mgoertz-msft]

No plans at the moment. Icon support will be a little harder since we don't actually load the assemblies and therefore cannot get to the embedded resources where the icons usually are.

[jnm2]

I see, too bad. Looks like you'd need https://github.com/dotnet/corefx/issues/23372.

[mgoertz-msft]

Yes, that would help. Of course I would need that on .NET Framework and not just Core.

[Misiu]

@mgoertz-msft thanks for the update, I'll try that right away.
Icon support isn't that important, but it would be a cherry on top :)

After adding a class that inherits Control everything works fine - control shows in the toolbox, but category name is the name of my NuGet package. I cannot change the category name.
I've tried adding [assembly: AssemblyProduct("Test")] attribute to my class but in VS 15.8.9 I get this warning:

Is this feature somewhere documented? Or maybe there is a sample NuGet package we can check as a reference?

[jnm2]

@Misiu An attribute can't target both an assembly and a class. If it has assembly:, it's assembly-wide. (docs)

[jnm2]

@mgoertz-msft I'm interested in the ability to keep design-time assemblies in the nupkg, both as a producer of multiple Windows Forms libraries and as a customer of DevExpress who I wish would also be able to use this.

The company I work with has had issues with the design-time assemblies being resolved through HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.5.50709\AssemblyFoldersEx\Foo because they conflict with the newer runtime assemblies referenced via NuGet. It would be better to version the design-time assemblies within the nupkg along with their matching runtime assemblies. Maybe the convention could be to keep them under design/net46, etc?

If this isn't something you're already working on, may I open a new issue?

[Misiu]

@jnm2 thanks for the hint, now it works fine 😄
P.S.
Do You know how to add information about version and company like in .NET Controls?

[jnm2]

@Misiu Yes. So long as our Windows Forms projects require us to use the legacy csproj format and there's no way to set this in the csproj, you use the AssemblyInfo.cs file:

```c#
// Shows up as company in Windows Explorer file properties
[assembly: AssemblyCompany("Misiu Corp.")]

// Shows up as product name in Windows Explorer file properties
[assembly: AssemblyProduct("Misiu.Controls")]

// Shows up as copyright in Windows Explorer file properties
[assembly: AssemblyCopyright("Copyright © 2018 Misiu Corp.")]

// Sets .NET assembly version and shows up as file version in Windows Explorer file properties
[assembly: AssemblyVersion("1.2.3")]

// Shows up as product version in Windows Explorer file properties
// Right now it's redundant because it defaults to AssemblyVersion, but I have a build script that
// modifies this one to 1.2.3+build.5678.commit.e6e24391d in CI.
[assembly: AssemblyInformationalVersion("1.2.3")]

// Shows up as Windows Explorer file description and as "Open with" description if this was an EXE
[assembly: AssemblyTitle("Misiu user interface components")]
```

If you have multiple projects in your solution that ship to production, I'd suggest putting only AssemblyTitle in each AssemblyInfo.cs and putting the rest in a CommonAssemblyInfo.cs file next to the solution, and linking that file in under the Properties folder of each csproj. (To link, drag the file into Solution Explorer and hold Ctrl+Shift while letting go.)

[Misiu]

@jnm2 I have all of those in my AssemblyInfo.cs but after building m NuGet and adding it to test project I see my user control, but after hovering on Toolbox I don't see version and company info.
Try hovering over one of the standard (built-in) controls and then on Your custom control. You will see an additional line:
Version 4.6.1.0 from Microsoft Corporation (just like on image from my previous comment).

I want to add Version 1.2.3 from Misiu Corp. to all of my controls and would like to have that when I hover over control in Toolbox.

Not sue if this is possible when sharing controls via NuGet.

[jnm2]

Oh, I see. I'm not sure I can answer that. @mgoertz-msft?

[Misiu]

@jnm2, @mgoertz-msft could You take a look at this: https://github.com/dotnet/corefx/issues/23372#issuecomment-484481574?
How are icons read right now when controls are selected from DLL? Is there any potential risk to do that at runtime?

[mgoertz-msft]

@Misiu Sorry, this had dropped off my radar. It looks like Version is already supported for NuGet assemblies but Company name is not. This is what shows up for the WebView control:

@Misiu Just like with the icon request, I would suggest that you create a feedback ticket for this through VS so it gets tracked in our work item tracking system in VS. That way it can also get upvoted, which would increase the priority of this investigation. Please mention my name somewhere in the description or add the link here so I can find it and make sure it ends up in the right spot.

[Misiu]

@mgoertz-msft I've created a feature request for Company attribute: https://developercommunity.visualstudio.com/idea/539607/support-company-attribute-for-user-controls-instal.html
and for icon support: https://developercommunity.visualstudio.com/idea/539616/user-controls-installed-via-nuget-should-display-i.html

Please moderate them if needed. Hopefully, this will be added at some point, ideally to VS2019 and VS2017.
I think that not only big players (DevExpress, Telerik, Syncfusion, etc) will be happy with those improvements 🙂

[mgoertz-msft]

@Misiu Got them, thank you! No promises though on if or when these will be addressed but at least we have them in Visual Studio's tracking system now, which will notify you of any changes to these tickets.

[Kannan1015]

@mgoertz-msft , the .NET Framework assemblies are loaded in the Visual Studio 2019 toolbox when installing the NuGet package. But, the custom control is not configured in toolbox for .NET Core 3.0 WinForms application. Do we have the solution for this?

[nkolev92]

Walking through this thread, are there any asks from NuGet that are not captured in other issues?
@mgoertz-msft

[nkolev92]

Duplicate of https://github.com/dotnet/winforms-designer/issues/202.

Please track that effort there.

Thank you all.

[jnm2]

@nkolev92 https://github.com/dotnet/winforms-designer/issues/202 gives me a 404. Can there be a public thread to track, please?

[nkolev92]

Oh my bad.
I've reached out to people on the team for input on that.