ProduceReferenceAssembly causes stale assemblies in legacy C# project system

[Suchiman]

Version used: VS15.3

Reproduction steps:

1. Create a new .NET 4.7 console application
2. Add a class library project
3. Add a project reference from the console application to the class library
4. Unload the class library and add this to the first unconditional property group

   <Deterministic>true</Deterministic>
   <ProduceReferenceAssembly>true</ProduceReferenceAssembly>

5. Reload the class library
6. (optional, doesn't change the outcome) Close VS and remove the .vs, obj and bin folder and reopen VS
7. In the class library project, add a class like the following:

   using System;
   
   namespace Lib
   {
       public static class Tester
       {
           public static void Test()
           {
               Console.WriteLine("Hello you");
           }
       }
   }

8. Call this method from the console application

   using Lib;
   
   namespace Startup
   {
       class Program
       {
           static void Main(string[] args)
           {
               Tester.Test();
           }
       }
   }

9. Ensure that the console application is the startup project
10. Start debugging by pressing F11
11. Step through the entire program once to confirm everything is working as expected
12. Stop debugging
13. In the class library, modify Console.WriteLine("Hello you"); to Console.WriteLine("Hello World");
14. Save
15. Start debugging again using F11
16. Step into Tester.Test();

Expected Result
Works the same as the first time

Actual Result
the source file is different from when the module was built

[rainersigwald]

@jcouv, did we get the reference-assembly-as-project-input fix into the legacy project system for 15.3? I remember it being tight for the new project system . . .

[jcouv]

Only the new project system works, and still the feature is not finalized (consider beta).
The Roslyn team just started dogfooding. The plan is to announce for general availability in version 15.5, assuming we can iron out sufficiently.

@srivatsn @Pilchie can you triage/assign while I'm away? Thanks

[dasMulli]

The plan is to announce for general availability in version 15.5, assuming we can iron out sufficiently.

Any update on how well the feature works now that 15.5 is out?

[nguerrera]

Is this a duplicate of dotnet/project-system#4079, which was closed "won't fix"? @tmeschter

[tmeschter]

@nguerrera Related to dotnet/project-system#4079, but this goes beyond the issues listed there. That is, fixing dotnet/project-system#4079 is probably required but not sufficient to fix this.

[rainersigwald]

@drewnoakes @donJoseLuis is there a better tracking item for this csproj.dll work? It's been lost here for years but we also keep talking about it internally.