Default ProduceReferenceAssembly to true

[dasMulli]

Get better incremental build performance by opting in to reference assembly based builds by defaulting ProduceReferenceAssembly to true.

Since this is a behaviour change, it may be good to do it in 3.0 and for SDK projects only.

[dasMulli]

@peterhuene I'm not sure who I should mention for this.

maybe @rainersigwald has more info about the current support for this across project systems, he mentioned a year ago that the classic project systems may have troubles with it, but that was when the feature was newly implemented.

[rainersigwald]

@davkean were you looking into this?

[dasMulli]

@davkean ping 😄

@rainersigwald @dsplaisted @peterhuene @livarcocc @nguerrera any objections?

[rainersigwald]

I'm still worried about the effect in VS on projects that have a reference to an SDK project but are themselves a non-SDK csproj-project-system project. Would love to find out that that's all been fixed but I don't think it has, yet.

[nguerrera]

cc @Pilchie My understanding is that we intend for this to be the default in 3.0

I'm still worried about the effect in VS on projects that have a reference to an SDK project but are themselves a non-SDK csproj-project-system project

Are you worried about a mix of projects with ProduceReferenceAssembly=true/false irrespective of SDK/non-SDK? Shouldn't that be supported?

Would love to find out that that's all been fixed but I don't think it has

What is it that might not be fixed?

[rainersigwald]

Are you worried about a mix of projects with ProduceReferenceAssembly=true/false irrespective of SDK/non-SDK?

Yes--but it gets worse if all SDK projects flip the switch.

What is it that might not be fixed?

Incremental build scenarios in VS like those fixed in the CPS project system by dotnet/project-system#2414 and its follow-ups.

[nguerrera]

Incremental build scenarios in VS like those fixed in the CPS project system by dotnet/project-system#2414 and its follow-ups.

@panopticoncentral @Pilchie Are there such issues in the classic project system still unfixed? Are they tracked? Is it feasible to get them fixed in dev16?

[rainersigwald]

Ok, I did a small proof-of-concept that things are still broken.

MixedSolutionWithRefAssemblies.zip

This solution has:

• An SDK netstandard library that produces reference assemblies
• A net472 .exe
• A net472 unit test project

The unit test project tests library functionality by calling the app that calls the library.

1. Open up the solution in VS and run the test through the UI.

========== Build: 3 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

2. It fails, because there's an error in the library. It subtracts instead of adds.
3. Fix the error:

diff --git a/Lib/Class1.cs b/Lib/Class1.cs
index a33c4c0..76a1c90 100644
--- a/Lib/Class1.cs
+++ b/Lib/Class1.cs
@@ -6,7 +6,7 @@ namespace Lib
     {
         public static int Add(int a, int b)
         {
-            return a - b; // note deliberate error
+            return a + b;
         }
     }
 }

4. Run the test again.
5. The test still fails, because

========== Build: 1 succeeded, 0 failed, 2 up-to-date, 0 skipped ==========

That's because the fast-up-to-date check in csproj doesn't understand that it needs to tell MSBuild to build the app even though its direct input (the lib.dll reference assembly) hasn't changed. CoreCompile will be skipped, but the build will copy the implementation assembly along, so that the updated implementation is available at runtime.

[nguerrera]

Thanks, @rainersigwald. I filed this as dotnet/project-system#4079, which we think from the discussion yesterd would be blocking this.

[Pilchie]

Ugh - I wasn't aware that there were still issues here :(

[nguerrera]

dotnet/project-system#4079 is closed as won't fix. Does this mean we can never turn this on by default? :(

cc @tmeschter @jjmew @livarcocc