Build Acceleration with netstandard

[persn]

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.

[drewnoakes]

@persn thanks very much for the feedback! I've taken a look and understand the issue.

tl;dr: Add property <ProduceReferenceAssembly>true</ProduceReferenceAssembly> to your projects.

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, ProduceReferenceAssembly was only set to true by default when targeting net5.0 or later. No provision was made for netstandard*.*. I suspect enough time has passed now that we can revisit these defaults to include more projects, and filed dotnet/sdk#30792 to cover your case. I'll start a discussion between some VS teams, MSBuild and the SDK as to whether we can change the defaults to be even more permissive in future.

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 ProduceReferenceAssembly alongside your AccelerateBuildsInVisualStudio property.

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.

[drewnoakes]

#8870 will help identify cases like this in 17.6 and later.

[persn]

I have tested now, and it worked pretty much instantly when I set <ProduceReferenceAssembly>true</ProduceReferenceAssembly> in my Directory.Build.props. Which makes this seem stable enough that I'll apply those changes to our main branch and then I'll see if any other issues pop up when the rest of the devs starts compiling code. Will open new issues in that event.

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

1. 04:24:057
2. 03:46:149
3. 04:17:786
4. 03:40:603
5. 03:44:969

Visual Studio 17.5 with Build Acceleration

1. 00:07:309
2. 00:05:483
3. 00:05:459
4. 00:05:767
5. 00:05:273

[drewnoakes]

@persn thanks for confirming. I'm really glad to see the feature's had such a huge impact on your build times!

[jamesc-skyward]

Is this intended to work with .NET Framework using SDK-style projects?

[drewnoakes]

@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:

• You need to ensure ProduceReferenceAssembly is set to true for your projects. The default for .NET Framework projects is false. Producing reference assemblies is a good idea regardless of whether you're using Build Acceleration.
• Targeting .NET Framework from SDK-style projects is not technically supported, however we do our best to make this work and are not aware of any major blockers.

[drewnoakes]

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.