Legacy project system fast up-to-date check does not work with ProduceReferenceAssembly=true

[nguerrera]

@rainersigwald wrote:

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.

[rainersigwald]

Related changes in CPS:

• spec (not sure how up to date): Up-to-date check awareness of reference assemblies #2254
• implementation: Handle ref assemblies in up-to-date check #2414

[tmeschter]

Tom's triage notes: probably not hard to fix (I think the problem is we're only considering the reference assembly as an output item and not also the implementation assembly) but not something I think we have to fix, either.

[tmeschter]

Ah, no, it's a little more complicated than that: we need to consider both the reference assembly and implementation assemblies to be outputs, and for each input reference if there is an associated implementation assembly we need to consider that input as well.

[tmeschter]

After further review of the spec (#2254) and implementation (#2414) for the CPS-based project system, I've decided this will be more complicated than initially thought to implement for CSProj. As such, we're not going to fix this.

[drewnoakes]

This was added in a recent 17.x build.