[msbuild] Use MSBuild assemblies from NuGet instead of Mono's installation.#21471
[msbuild] Use MSBuild assemblies from NuGet instead of Mono's installation.#21471rolfbjarne merged 2 commits intomainfrom
Conversation
…ation. Use MSBuild assemblies from NuGet instead of Mono's installation. Try to get the closest version to Mono's assemblies. This avoids a Mono dependency.
| <PackageReference Include="Microsoft.Build" Version="15.1.548" /> | ||
| <PackageReference Include="Microsoft.Build.Framework" Version="15.1.548" /> | ||
| <PackageReference Include="Microsoft.Build.Tasks.Core" Version="15.1.548" /> | ||
| <PackageReference Include="Microsoft.Build.Utilities.Core" Version="15.1.548" /> |
There was a problem hiding this comment.
@rolfbjarne Any reason to not use latest version? I am just concerned that we may bring security issues this way.
There was a problem hiding this comment.
I'm not sure if we need to keep the old versions at this point. I think we could try bumping to newer ones and test it. What do the task assemblies depend on?
There was a problem hiding this comment.
Trying with the latest, let's see what CI says.
@emaf what's the latest desktop TFM that works in VS? Can we use "net4.8.1" or do we have to use something older?
I'm asking because we're building for netstandard2.0 in some of the projects, and that results in this warning:
warning NU1701: Package 'Microsoft.Build 17.11.4' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
There was a problem hiding this comment.
@emaf Looks like using the latest versions is fine, but note that we're not running any tests from within VS, so if this breaks VS on Windows, our tests won't detect it.
There was a problem hiding this comment.
As the build agent does not directly interact with VS, it should not make any difference. I gave this a quick try and seems to work fine.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ API diff for current PR / commit.NET (No breaking changes)✅ API diff vs stable.NET (No breaking changes)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
💻 [CI Build] Windows Integration Tests passed 💻✅ All Windows Integration Tests passed. Pipeline on Agent |
💻 [CI Build] Tests on macOS X64 - Mac Sonoma (14) passed 💻✅ All tests on macOS X64 - Mac Sonoma (14) passed. Pipeline on Agent |
💻 [CI Build] Tests on macOS M1 - Mac Ventura (13) passed 💻✅ All tests on macOS M1 - Mac Ventura (13) passed. Pipeline on Agent |
💻 [CI Build] Tests on macOS M1 - Mac Monterey (12) passed 💻✅ All tests on macOS M1 - Mac Monterey (12) passed. Pipeline on Agent |
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 101 tests passed 🎉 Tests counts✅ cecil: All 1 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
… instead of Mono's installation. (#21471)" (#21670) This reverts commit 71a29e3. This seems to be breaking windows see: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2304182
7 participants
Use MSBuild assemblies from NuGet instead of Mono's installation. Try to get
the closest version to Mono's assemblies.
This avoids a Mono dependency.