Build Acceleration with netstandard #8865
Comments
In general we want to produce reference assemblies whenever possible, as they improve incremental build performance. However they require support from other components, such as the fast up-to-date check in VS. While support was originally added for SDK-style projects, it was not present for legacy `.csproj` files. Accordingly, `ProduceReferenceAssemblies` was set `true` only when the target framework was `net5.0` or later (and `net7.0` for F#). VS 17.5 ships the new Build Acceleration feature, which works best when used in conjunction with reference assemblies. A customer reported in dotnet/project-system#8865 that builds in their .NET Standard projects were not accelerated. Investigation shows this is because reference assemblies are not produced for such projects. This change enables the production of reference assemblies for all (non-F#) projects targeting .NET Standard.
|
@persn thanks very much for the feedback! I've taken a look and understand the issue. tl;dr: Add property Build Acceleration works best when your solution is configured to produce reference assemblies. By default, whether reference assemblies are produced depends upon the target framework. For back-compat reasons, We have work item #8798 which would have prompted you to be able to address this yourself, and I hope to get that into 17.6. In the meantime, it should be straightforward for you to set I'll be sure to add this information to the documentation for future. Thanks again for the feedback. Please try out the above and let me know if it works for you. |
|
#8870 will help identify cases like this in 17.6 and later. |
|
I have tested now, and it worked pretty much instantly when I set Just for fun, here are some numbers I gathered when testing editing on of our core libraries in our largest solution followed by a build: Visual Studio 17.5 without Build Acceleration
Visual Studio 17.5 with Build Acceleration
|
|
@persn thanks for confirming. I'm really glad to see the feature's had such a huge impact on your build times! |
|
Is this intended to work with .NET Framework using SDK-style projects? |
|
@jamesc-skyward yes, this will work. In fact, this very repo targets .NET Framework with SDK-style projects and uses Build Acceleration. A few caveats though:
|
drewnoakes
added
the
Feature-Build-Acceleration
|
I'm going to close this as complete. Build Acceleration is working for you. We've extended the documentation with details for others to benefit from. We've added log output to warn about this situation in 17.6. I'm working to have .NET Standard projects produce reference assemblies by default. Thanks again for the feedback. Do let us know if you have any other thoughts or issues with the feature. |
…puts have the 'ProduceReferenceAssembly' MSBuild property set to 'true': 'D:\GitWorkspace\ILSpy\ICSharpCode.Decompiler\bin\Debug\netstandard2.0\ICSharpCode.Decompiler.dll'" - this relates to the documented problem of netstandard2.0 projects not generating the necessary reference assemblies (direct issue link dotnet/project-system#8865) No harm for netcore projects as these produce those ref asms by default.
* Accelerate builds of SDK-style .NET projects https://github.com/dotnet/project-system/blob/main/docs/build-acceleration.md#validate-builds-are-accelerated * Verbose logging produced "Ensure projects producing the following outputs have the 'ProduceReferenceAssembly' MSBuild property set to 'true': 'D:\GitWorkspace\ILSpy\ICSharpCode.Decompiler\bin\Debug\netstandard2.0\ICSharpCode.Decompiler.dll'" - this relates to the documented problem of netstandard2.0 projects not generating the necessary reference assemblies (direct issue link dotnet/project-system#8865) No harm for netcore projects as these produce those ref asms by default.
Visual Studio Version
Version 17.5.0
Summary
I was going to try and see if we could use build acceleration at my workplace, however I couldn't make it trigger and it always built all my project dependencies when I made a simple edit in one of the source files at one of our core libraries. Eventually I discovered that if I changed the target framework to net6.0 from netstandard2.0 it worked as expected.
I can understand there might be some technical reason netstandard projects doesn't get build acceleration, not sure if that is the case, but if it is it should probably be listed as a prerequisite, which AFAICT it is not https://github.com/dotnet/project-system/blob/main/docs/build-acceleration.md#validate-builds-are-accelerated
Steps to Reproduce
Using this as an example.. If Library 3 has target framework netstandard2.0, and I make a change to to Library 3, it will trigger all 4 MSBuild calls instead of being called once like it states in the link. If I change to net6.0 it works as expected, it also works if I multi-target
<TargetFrameworks>netstandard2.0;net6.0</TargetFrameworks>.Expected Behavior
I would expect projects with netstandard to support build acceleration as I can't see any documentation that states otherwise, or I would expect the documentation to make target framework demands more clear.
Actual Behavior
Build acceleration doesn't trigger when I make a simple change in one of my core libraries, instead the entire source gets built like it always did. Documentation doesn't mention any target framework requirements
User Impact
We have a very large codebase that we're working on migrating to net6.0, however the majority of the codebase will have to continue to build to netstandard until we we can rid ourselves of all legacy demands which will take along time. Without netstandard support we cannot use this feature which otherwise looks excellent.
The text was updated successfully, but these errors were encountered: