Converting extension SDKs into NuGet Packages

[harikmenon]

Details for the spec available here

https://github.com/NuGet/Home/wiki/Converting-Extension-SDKs-into-NuGet-Packages

[jnm2]

It would be amazing if this lit up for Windows Forms projects too:

<?xml version="1.0" encoding="utf-8"?>
<FileList>
  <File Reference="CompanyName.Controls.dll">
    <ToolboxItems VSCategory="CompanyName">
      <Item Type="CompanyName.Controls.ControlName" />
    </ToolboxItems>
  </File>
</FileList>

Would you please consider this?

[debonte]

Thanks for the suggestion @jnm2. I'll pass this on to the Winforms team.

[jnm2]

Thank you. This is causing pain as my company is migrating many internal libraries from shared projects to internal NuGet packages.

[jnm2]

I've gotten so close to having an okay workaround!

• Choose a target framework and copy the lib DLL to /tools/design
• Copy any dependency assemblies it needs to the same nupkg directory so that it can be loaded at design time
• Add this file as /tools/Init.ps1

Result (only tested with <PackageReference>):

• The first time you install the package from the package manager, the toolbox gets set up the way you'd want it. VS saves the toolbox state when it closes.
• Adding a control to a form does the right thing to your project references (nothing) if you have a package reference. However if you beat VS to package restore (not likely unless you're trying), you can totally trash your project references.
• If you didn't use the package manager, or you delete the toolbox items and want them back, you have to go the the menu and choose View > Other Windows > Package Manager Console. This will cause Init.ps1 to run and the items to be inserted into the toolbox.

Init.ps1 is a super ugly hack and I should not be forced into doing this, but this is the state of the art with Windows Forms and NuGet. Please let Windows Forms controls be autodiscovered via PackageReference just like you already do with XAML controls.

Potential improvements to the hack:

1. Add a .props that uses InitialTargets to obtain a DTE reference and run Init.ps1 so that you no longer have to go the the menu and choose View > Other Windows > Package Manager Console to get Init.ps1 to run if you need fix the toolbox. Yup, this is ugly too, but not as ugly as having to open the package manager console to get intuitive behavior from the toolbox.

2. Instead of using the $DTE object already present, read the whole running object table and repeat the toolbox item installation for every open instance of VS. The last VS instance to close overwrites the whole toolbox, so if you install the NuGet package in only one of them and then close it before closing the other one, the toolbox items are gone and you have to repair it (see improvement 1 for autorepair)

Improvement 2 is debatable. This is all stuff VS should be doing; there's no way to remove the toolbox items when you open a project that doesn't reference the package, even though you really should.

[jainaashish]

Done in Visual Studio 2017 15.2

[MikhailTymchukDX]

The code sample in wiki has error:

<FileList>
  <File Reference = “YourReferenceAssembly.winmd”>
  <ToolboxItems VSCategory = “YourFolderName” BlendCategory=" YourFolderName">
    <Item Type="Namespace.Type1" />
    <Item Type="Namespace.Type2" />
    <Item Type="Namespace.TypeEtc" />
  <ToolboxItems/>
  </File>
</FileList>

ToolboxItems tag improperly closed. The valid code is the following:

<FileList>
  <File Reference = "YourReferenceAssembly.winmd">
    <ToolboxItems VSCategory = "YourFolderName" BlendCategory=" YourFolderName">
      <Item Type="Namespace.Type1" />
      <Item Type="Namespace.Type2" />
      <Item Type="Namespace.TypeEtc" />
    </ToolboxItems>
  </File>
</FileList>

[debonte]

@MikhailTymchukDX, that's the feature spec and as a spec might have errors. The final documentation is available here: https://docs.microsoft.com/en-us/nuget/guides/create-uwp-controls

[ghost]

Are there any updates on this issue? I'm still needing to have Controls automatically added to the Visual Studio Toolbox.

[debonte]

@jasonpezzimenti Not sure what you're referring to. WinForms support?

[jnm2]

@debonte Yes, I believe he is. I'm also anxious to hear from the WinForms team.

[ghost]

@debonte Sorry for the delay, I am referring to that. It would be awesome if we could finally have Toolbox support for Windows Forms controls.

[Misiu]

@jainaashish any news about WinForms support?

[jainaashish]

@anangaur @karann-msft can you help answer this?

[jainaashish]

@Misiu can you please follow on #6440 which is the current issue targeting this winforms support ask?

[debonte]

@mgoertz-msft, can you answer this?

[mgoertz-msft]

I provided an answer in #6440