Attempting to GenerateReferenceSource for System.Runtime fails

[tannergooding]

As per the title, the following fails:

D:\tagoo\Repos\runtime\src\libraries\System.Runtime\src> dotnet msbuild /t:GenerateReferenceSource /p:Configuration=Release
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Unable to resolve assembly 'Assembly(Name=System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)' referenced by 'Microsoft.Cci.DummyModule'

[ghost]

Tagging @safern, @ViktorHofer as an area owner

[safern]

cc: @ericstj

I repro this locally. We're missing two things here for assemblies that have a ReferenceFromRuntime. We need to pass down the --follow-type-forwards argument and also, instead of use the ref\netcoreapp* directory as --lib-path we should pass the runtime dir for libraries and the coreclr dir using the liveBuild.targets targets to get the runtime files.

[ericstj]

So the way I'd expect this to work is that --follow-type-forwards is the default for any project that uses ReferenceFromRuntime (assuming it isn't already set) and for --lib-path it gets derived from all the directories passed as @(ReferencePath) to the compiler.

[safern]

and for --lib-path it gets derived from all the directories passed as @(ReferencePath) to the compiler.

Right, however for that we would need to make GenerateReferenceSource depend on ResolveAssemblyReferences target because right now ReferencePath itemgroup is not populated.

[pgovind]

Not sure if this is something specific to me, but after I updated my System.Runtime.cs file, VS started crashing when I tried to open it.

[danmoseley]

VS crash? That's not good - can you get a callstack? Let's get a bug opened against them

[pgovind]

Yup yup. I'm going to be debugging this a little later and will capture a log then.