Question: Packaging of Roslyn analyzer nuget

[nschuessler]

I have gotten some feedback on my analyzer NuGet package from a customer.

The 'Bug' is that my analyzer NuGet package has dependencies on other NuGet packages and that causes problems.
When adding my analyzers package to a project I get an entry like this:

 <ItemGroup>
    <PackageReference Include="My.Analyzers" Version="403.22.1118.2">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

There are only analyzers in the package, but I suspect because build and/or runtime are added by default, that this ties my analyzer runtime to the target of the project and causes customer issues (i.e. if I built my analyzer for .Net 6.0, it wouldn't work in targeting a net framework project)?

My NuGet is built using an exclusion list found in an article online:

        <file src="bin\Release\*.dll" target="analyzers\dotnet" exclude="**\Microsoft.CodeAnalysis.CSharp.*;**\Microsoft.CodeAnalysis.VisualBasic.*;**\Microsoft.CodeAnalysis.dll;**\Microsoft.CodeAnalysis.Workspaces.dll;**\System.Collections.Immutable.*;**\System.Reflection.Metadata.*;**\System.Composition.*" />

But because my ADO pipeline runs a script to patch the .nuspec with dependencies derived from the PackageReference entries in the .csproj, the NuGet has dependencies, causing them all to be installed.

Questions:

1. Is the right thing to do to remove the NuGet package dependencies and include the flat files only (vs remove the flat files and go with the

2. My understanding is your install script must install all binaries into Visual Studio IDE to be able to find the dependencies for complex analyzers, even if the binaries don't contain the actual analyzer .. correct? This yields to ugly UI vs the organized (nested) NuGet package dependencies UI:

3. There seems to be bad problems whether you include binaries in your analyzers NuGet or not. Will there be an effort to make this cleaner for developers?

i.e.

• By including binaries from other NuGet packages in yours, you are signing (vouching for the security of) packages you don't build or have source for and are on the hook for re-releasing your analyzer any time there is a security fix for any of the dependencies.
• You lose all the benefits of the NuGet package system: smaller NuGet packages, ease of finding and upgrading to dependencies with security fixes, re-use of cached NuGet binaries, automatic fixing of conflicting (multiple) binary versions. Shouldn't the IDE realize that build; analyzers; necessarily have different dependencies and shouldn't be put together? i.e. you can't ship multiple platform targets under (analyzers\cs\...) can you?
• Packaging automation has to be customized for analyzer packages to exclude dependencies on the NuGet package.

Thanks

[arkalyanms]

@mavasani to assess if we can make a recommendation here.