Specify PrivateAssets="all" #9328
Conversation
The Microsoft.Net.Compilers.Toolset package does not contain libraries to reference; rather, it allows us to pick up different versions of the C# compiler and associated MSBuild files than what we would normally get from the SDK. As a NuGet package, however, it is subject to the same transitive reference rules as every other package and that means that consumers of our Microsoft.VisualStudio.ProjectSystem.Managed NuGet package _also_ end up depending on Microsoft.Net.Compilers.Toolset whether or not they want to. This means we're changing how consuming projects build in a way that has nothing to do with the functionality they need from Microsoft.VisualStudio.ProjectSystem.Managed which is not what was intended. We see this in other repos using Microsoft.Net.Compilers.Toolset; NuGet complains if they are not using the same version of the package. Here we fix this by specify that all the assets of the package are private, meaning that they will be used by projects that reference Microsoft.Net.Compilers.Toolset but will not be passed on transitively. We already do this with other packages that are used strictly to modify the build.
tmeschter
added
the
Area-Infrastructure
| @@ -12,7 +12,7 @@ | |||
| <!-- Path Property: PkgMicrosoft_DiaSymReader_Pdb2Pdb --> | |||
| <PackageReference Include="Microsoft.DiaSymReader.Pdb2Pdb" ExcludeAssets="all" GeneratePathProperty="true" /> | |||
| <PackageReference Include="Microsoft.DotNet.XliffTasks" PrivateAssets="all" /> | |||
| <PackageReference Include="Microsoft.Net.Compilers.Toolset" /> | |||
| <PackageReference Include="Microsoft.Net.Compilers.Toolset" PrivateAssets="all" /> | |||
There was a problem hiding this comment.
We should re-evaluate whether or not we need this package to begin with. It exists to give you a way to pick up a different version of the compiler than you get with the SDK, and this can be useful if you are stuck with an SDK with a compiler bug or want to use a compiler feature not available through the SDK. However, we don't use lock ourselves to a particular SDK with global.json and frequently have pre-release SDK builds on our systems. As such, the compiler we've chosen here will often be older than the SDK we're using, and sometimes newer, but we're not controlling the relationship between them in any meaningful way.
There was a problem hiding this comment.
I like that this package lets us dogfoods new compiler bits in a way that works for all developers who might open this repo. If we leave it to the SDK, then developers on older SDKs won't be able to compile.
|
@haileymck I don't think |
|
Closing in favor of #9329. |
|
Re-opening as there is ongoing discussion RE: #9329. |
ghost
added this to the
The Microsoft.Net.Compilers.Toolset package does not contain libraries to reference; rather, it allows us to pick up different versions of the C# compiler and associated MSBuild files than what we would normally get from the SDK. As a NuGet package, however, it is subject to the same transitive reference rules as every other package and that means that consumers of our Microsoft.VisualStudio.ProjectSystem.Managed NuGet package also end up depending on Microsoft.Net.Compilers.Toolset whether or not they want to.
This means we're changing how consuming projects build in a way that has nothing to do with the functionality they need from Microsoft.VisualStudio.ProjectSystem.Managed which is not what was intended. We see this in other repos using Microsoft.Net.Compilers.Toolset; NuGet complains if they are not using the same version of the package.
Here we fix this by specify that all the assets of the package are private, meaning that they will be used by projects that reference Microsoft.Net.Compilers.Toolset but will not be passed on transitively. We already do this with other packages that are used strictly to modify the build.
Microsoft Reviewers: Open in CodeFlow