.NET projects produce a reference assembly by default #8571
Conversation
In general we want to produce reference assemblies whenever possible, as they improve incremental build performance. Making them work end-to-end requires support from other components, such as fast up-to-date checks 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 for C#/VB projects. Similarly, F# added support during `net7.0`, so a similar check was added for F# projects. VS 17.5 ships support for reference assemblies in the legacy CSPROJ fast up-to-date check, so all C#/VB projects are supported. Similarly, F# has full support. Consequently, it is now safe to enable the production and consumption of reference assemblies across all .NET project types, including .NET Framework, .NET Standard, .NET Core and .NET. This commit changes the default `ProduceReferenceAssembly` value to `true` for all .NET projects.
The removed text exists in other files where it makes sense. It seems to be here due to copy/paste followed by an incomplete edit.
There was a problem hiding this comment.
Thank you.
I cannt think of any associated risk - but I'd prefer someone more experienced to have chance for last call - @rainersigwald, @ladipro?
|
I would like to hold this for 17.6 preview 1 if there's no critical need for it now. |
Makes sense to me. I believe we'll also have to update SDK tests in response to this change. |
Forgind
added
merge-when-branch-open
@drewnoakes, are you planning to update the SDK tests/already updated the SDK tests? If so, once we have builds working properly, we think this is ready to go in. |
I'm trying these changes in the SDK repo to understand what tests needed to be updated. So far I found only |
|
A first draft of the SDK changes are at: dotnet/sdk#31598 |
|
This change breaks with cached builds (project cache). Specifically when the version of msbuild being used to generate the cache output is older than the one being used on the developer's desktop. We get a cache hit because the input hash matches but the project cache outputs are missing the reference assembly. |
This reverts commit 6487653.
drewnoakes
deleted the
dev/drnoakes/enable-reference-assembly-by-default
branch
|
I believe this change broke the .NET 8 Android workload's build in dotnet/android#7979: I'm sure I can workaround, but I thought I'd share the log above if it is useful to understand how it might impact customers. |
|
This change has been rolled back in the latest int preview.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Jonathan Peppers ***@***.***>
Sent: Friday, April 21, 2023 8:07:54 AM
To: dotnet/msbuild ***@***.***>
Cc: Mark Osborne ***@***.***>; Comment ***@***.***>
Subject: Re: [dotnet/msbuild] .NET projects produce a reference assembly by default (PR #8571)
I believe this change broke the .NET 8 Android workload's build in dotnet/android#7979<dotnet/android#7979>:
Build Results.zip<https://github.com/dotnet/msbuild/files/11296978/Build.Results.zip>
I'm sure I can workaround, but I thought I'd share the log above if it is useful to understand how it might impact customers.
—
Reply to this email directly, view it on GitHub<#8571 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADVMA7GUFCDQPTGMRFK4K33XCKPEVANCNFSM6AAAAAAV4T7TSI>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
@MarkOsborneMS we are using .NET 8, so I think we just need the latest dotnet/msbuild to flow to dotnet/installer now, thanks. I see the revert now: ac0b9a2 |
Definitely appreciated, thank you! |
…31598)" This reverts commit d2e470b, reversing changes made to 377caa7. Follows the MSBuild revert in dotnet/msbuild#8571.
In general we want to produce reference assemblies whenever possible, as they improve incremental build performance.
Making them work end-to-end requires support from other components, such as fast up-to-date checks in VS. While support was originally added for SDK-style projects, it was not present for legacy
.csprojfiles. Accordingly,ProduceReferenceAssemblieswas settrueonly when the target framework wasnet5.0or later for C#/VB projects. Similarly, F# added support duringnet7.0, so a similar check was added for F# projects.VS 17.5 ships support for reference assemblies in the legacy CSPROJ fast up-to-date check, so all C#/VB projects are supported. Similarly, F# has full support. Consequently, it is now safe to enable the production and consumption of reference assemblies across all .NET project types, including .NET Framework, .NET Standard, .NET Core and .NET.
This PR changes the default
ProduceReferenceAssemblyvalue totruefor all .NET projects.