-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Features projects to SourceBuild #57277
Add Features projects to SourceBuild #57277
Conversation
This would have made my last week easier 😛 EDIT: No it wouldn't, nevermind 😔 |
src/Features/LanguageServer/Protocol/Microsoft.CodeAnalysis.LanguageServer.Protocol.csproj
Outdated
Show resolved
Hide resolved
src/Features/Core/Portable/Microsoft.CodeAnalysis.Features.csproj
Outdated
Show resolved
Hide resolved
src/Features/Core/Portable/Microsoft.CodeAnalysis.Features.csproj
Outdated
Show resolved
Hide resolved
src/Features/Core/Portable/Microsoft.CodeAnalysis.Features.csproj
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General approach looks fine, but I agree that we want to change source build to build Roslyn.sln instead of Compilers.sln
Use Roslyn.sln, not Compilers.sln, to build more projects during source-build. Update ExcludeFromSourceBuild properties to include more projects and exclude a few projects that shouldn't be in source-build. The newly included projects are used by downstream repos.
This makes source-build stop producing the Microsoft.CodeAnalysis.Collections package. Downstream repos (MSBuild) can't safely use a source-built version.
By default, the projects reference Microsoft.Build 16.5.0, which has netcoreapp2.1 and net472 support. The new 17.0.0-... version built during source-build only has net6.0. This causes Microsoft.CodeAnalysis.Workspaces.MSBuild.csproj to fail. Adding 16.5.0 to SBRP and dodging the override by renaming each package version property is the safe way to fix it.
Updated with @dagood's change to build Roslyn.sln and to use RefOnly Microsoft.Build dependencies. @jasonmalinowski @tmat @jmarolf This is ready for another review |
@dagood How does this work, will these changes flowing into dev17.0-vs-deps be enough to satisfy source build requirements or will we need an additional insertion into the SDK? |
Integration build failures are expected and should be resolved separately by #57281 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe an SDK insertion would be needed to make the commit flow into this dependency: However, source-build will work fine if we take this PR and include it as a patch file in the dotnet/installer |
src/Compilers/Core/MSBuildTask/Microsoft.Build.Tasks.CodeAnalysis.csproj
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for getting to this so quick @JoeRobich!
Just one small suggestion for easier reading.
src/Features/CSharp/Portable/Microsoft.CodeAnalysis.CSharp.Features.csproj
Outdated
Show resolved
Hide resolved
src/Features/Core/Portable/Microsoft.CodeAnalysis.Features.csproj
Outdated
Show resolved
Hide resolved
src/Features/VisualBasic/Portable/Microsoft.CodeAnalysis.VisualBasic.Features.vbproj
Outdated
Show resolved
Hide resolved
<PackageReference Include="Microsoft.Build" Version="$(RefOnlyMicrosoftBuildVersion)" /> | ||
<PackageReference Include="Microsoft.Build.Framework" Version="$(RefOnlyMicrosoftBuildFrameworkVersion)" /> | ||
<PackageReference Include="Microsoft.Build.Tasks.Core" Version="$(RefOnlyMicrosoftBuildTasksCoreVersion)" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Should all uses of RefOnly*Version
versions have the ExcludeAssets="Runtime"
attribute?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should update BuildBoss to require the attribute if a RefOnly package is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would ExcludeAssets="Runtime"
cause the unit tests to fail in the Microsoft build? I assume the tests actually find and execute the MSBuild code when they run. (In source-build, unit tests don't build or run, so this isn't a concern there.) (But... it's very possible I don't understand the effect of ExcludeAssets="Runtime"
here.)
The name of these properties is misleading in this context for someone working on the Microsoft build. Really, any name that indicates these versions are "pinned" would do fine, if this is a concern.
In non-unit-test projects, ExcludeAssets="Runtime"
sounds like an interesting idea to me to exercise how ref-only they really are, in a Microsoft build.
Co-authored-by: Eric Erhardt <[email protected]>
@jasonmalinowski @tmat Any additional concerns before this is merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me, but I'm admittedly not the expert here!
SourceBuild will requires that all dependencies also be source buildable. We are referencing a | ||
version of MSBuild that is not SourceBuild compatible, which makes our build incompatible. Since we only | ||
use these dependencies as reference assemblies, we can opt them out of this behavior by having their | ||
version variable be prefixed with `RefOnly`. This will allow us to reference these libraries and remain | ||
Source Build compatible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a version of MSBuild we can be referencing that doesn't have this caveat?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dagood is MSBuild 16.11 compatible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought Davis did a good job of explaining the situation here: #57277 (comment). If you haven't read that, check it out.
If you name this property MicrosoftBuildVersion
, when building for source-build that property will automatically get overriden to point to the currently built version of Microsoft.Build.nupkg that was being built during source-build. This means this property would point to version 17.0-previewXXX
.
However, Roslyn's build doesn't succeed when trying to build against the current source-built MSBuild nuget packages (probably because your tasks projects are building for net472 and the source-build MSBuild packages didn't at the time - that was fixed yesterday dotnet/installer#12472).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'd have to use 17.0.0
(current latest that is being included in 6.0.100 SDK) and set up a eng/Version.Details.xml
dependency and subscription on MSBuild to make sure it's always up to date. Any version other than the one being shipped in the SDK needs this kind of ref-only handling.
My understanding is that this dependency is most likely stuck on an old version because it needs to be compatible with old VS toolsets, anyway--so moving to a non-16.5.0 & non-17.0.0 version wouldn't work from an MSBuild perspective, let alone source-build's.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If MSBuild 16.11 is source build compatible, I will update our dependency and revert the 'RefOnly' changes in a follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If MSBuild 16.11 is source build compatible
It's not, only an actively updated 17.0.0[-*]
would be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "caveat" is just too strong. Ref-only usage is everywhere, and it would be nice for source-build to get rid of it and have current references everywhere, but we expect old-ref-usage to stay in a lot of places because of the requirements the Microsoft build needs to fulfill. (E.g. NuGet packages need to be usable by people who are using old framework versions; VS has some complex compat requirements with the toolset it ships with.)
To me, this code comment is just a description of a normal process that is fine to have here. I filed dotnet/source-build#2546 so it can be hopefully be replaced with a link to a doc that describes this in more detail and with more context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that this dependency is most likely stuck on an old version because it needs to be compatible with old VS toolsets
@dagood @JoeRobich I'm not sure how well we support this library being used downlevel in that way -- it's not something we have automated test coverage for in any case. I'm not sure if this breaks folks that might have depended on our package and were also relying on us to have the dependency of some version if they didn't have another VS version on the box.
Resolves #57270