forked from dotnet/roslyn
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make Workspaces.MSBuild build with a netstandard target
Before this change we were building the Workspaces.MSBuild library (the part that loads in the end user's application process) as a .NET Core and .NET Framework library with no netstandard target, which meant that if we weren't careful we'd move our .NET Core TFM to something newer than what customers still expect us to support. All of our other libraries target netstandard but this one was still special. This was because some MSBuild NuGet packages themselves don't target netstandard and so we wre forced to do the same. Digging further we realized that Microsoft.Build.Framwork, which defines ILogger was already netstandard compatible, and so our only remaining use of an not-netstandard package was Microsoft.Build, which only existed to read solution files. That I fixed in our prior commit, so at this point the only NuGet packages we still referenced were .NET Standard compatible. Great! There wa one more surprise though: the BuildHost we ship as content files in subdirectories, but we were also shipping the DLL as a regular referenced library in the end user's application. This was to provide the serialization exchange types to the RPC client, as well as share some useful helpers that were needed on both sides. But since the BuildHost still cannot target netstandard because it does need MSBuild libraries that are not yet netstandard, it meant that the regular Workspaces.MSBuild.dll project couldn't reference the BuildHost DLL anymore either. So to break that link I move the handful of files we were needing on both sides to a shared project, and then just include that shared project into both the build host and library/client projects. This means we can break the ProjectReference link entirely. At some point MSBuild will make their other package netstandard, which means that split wasn't strictly necessary to do, but honestly it resulted in some downstream hacks so I believe it's a net win regardless. There was extra MSBuild/NuGet magic to make sure the binary was included in the other project without it appearing as a package reference. The only way to do that was to set PrivateAssets=all, which then meant other projects had to remember to reference that lest we fail to deploy a DLL. It was very much a fight against tooling, and severing the project references just cleans things up nicely. Fixes dotnet#71784
- Loading branch information
1 parent
794e6d4
commit fde57e0
Showing
23 changed files
with
72 additions
and
69 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.