Document how to create add-ins (and similar scenarios)

[richlander]

@RickStrahl is asking for guidance on creating add-ins: https://twitter.com/RickStrahl/status/1551342858774319104. We don't have a doc on that, AFAIK.

I believe the scenario is this:

• Addins can have any dependency.
• Dependencies that are already provided by the app should be knocked out.

We don't have a good way of doing this today. That's what dotnet/runtime#71282 is hoping to enable. The question is whether we have any facility for this today. It sounds like #30341 delivers at least part of that.

Related to

• Add DisableTransitiveProjectReferences #30341
• SDK: document DisableTransitiveProjectReferences #30340
• PrivateAssets = All does not prevent the dependency from flowing to another project msbuild#3996
• Enable shared libraries and runtimes for a software suite runtime#71282
• [Proposal] Pack ProjectReferences NuGet/Home#11708
• https://docs.microsoft.com/visualstudio/msbuild/tutorial-custom-task-code-generation?view=vs-2022#bundle-dependencies-into-the-package

@vitek-karas @rainersigwald @JonDouglas @baronfel @mhutch

[baronfel]

We do have a decent story for the 'knock out' part via the ExcludeAssets="runtime" mechanism. That's how MSBuild tasks don't bundle their own version of the MSBuild libraries, for example. That will end up being a key part of any story we tell here.

[richlander]

How does that work for inner loop or dotnet test, for example? This seems like another scenario where we might want knockout only for publish or something like that. Presumably, people building msbuild tasks (or other addins) have some way of doing development w/o the host. Or no?

[zivkan]

Another option is that the plugin host provides a package with ref/<tfm>/*.dll, but no lib/* or runtimes/*. That way package consumers don't need to manually use ExcludeAssets or similar. The VS SDK kind of does this, just in its own way, I think, rather than using NuGet's features (maybe because it's hard to pack assemblies into ref/?)

[vitek-karas]

Not sure if this fits the request but we have a guide and a sample for an app with plugins:
https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support

And it does discuss the exclusion of some dependencies...:

<ItemGroup>
    <ProjectReference Include="..\PluginBase\PluginBase.csproj">
        <Private>false</Private>
        <ExcludeAssets>runtime</ExcludeAssets>
    </ProjectReference>
</ItemGroup>

The sample app is here: https://github.com/dotnet/samples/tree/main/core/extensions/AppWithPlugin

[ericstj]

We do have a decent story for the 'knock out' part via the ExcludeAssets="runtime" mechanism. That's how MSBuild tasks don't bundle their own version of the MSBuild libraries, for example. That will end up being a key part of any story we tell here.

This doesn't work well in the project graph. If someone else brings in a reference to one of the excluded packages - even at a lower version - it will be included again. Conflict resolution is a better example of how we should drop components provided by the host. That's how shared frameworks work today.