.NET Core-based projects are not using the RAR cache in design-time builds

[davkean]

When I create a .NET Framework project, without building the following files exist in obj:

ConsoleApp1.csproj.CoreCompileInputs.cache
DesignTimeResolveAssemblyReferencesInput.cache

For .NET Core projects, the following files exist:

ConsoleApp126.AssemblyInfo.cs
ConsoleApp126.AssemblyInfoInputs.cache
ConsoleApp126.csproj.CoreCompileInputs.cache

Looks like we're skipping the cache (DesignTimeResolveAssemblyReferencesInput.cache is missing) in design-time builds. I don't know who's bug this is.

[Pilchie]

@AndyGerlicher - since you've been looking at RAR cache related stuff lately, do you know how to start investigating?

[Pilchie]

@AndyGerlicher Ping?

[Pilchie]

@AndyGerlicher or @cdmihai - ping?

[Pilchie]

@AndyGerlicher Andy Gerlicher FTE or @cdmihai Mihai Codoban FTE - ping? Should I move this to the MSBuild repo to start to get some traction on it?

[cdmihai]

Looks like this line is used to define the cache file name in full framework: https://github.com/Microsoft/msbuild/blob/master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L2558 (in a real build it's this: https://github.com/Microsoft/msbuild/blob/master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L2015). If the StateFile RAR parameter is not defined, RAR does not persist it's IO cache.

The state file is conditioned on BuildingProject=true. Looking at the design time build log for a .net core project, I see that BuildingProject is set to false.

I assume that BuildingProject should be false during design time builds, right @davkean? In that case:

• we should fix Design-time builds in CPS are doing too much work because BuildingProject is set to true msbuild#2417 to ensure that BuildingProject=false for all projects types
• fixing Design-time builds in CPS are doing too much work because BuildingProject is set to true msbuild#2417 will have the side effect (among probably other long tail of side effects) of turning off the RAR cache for full framework projects as well. For this, my proposal is to remove the condition on BuildingProject for https://github.com/Microsoft/msbuild/blob/master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L2558. RAR checks if the cache is invalid, so there shouldn't be any correctness issues.

Does this sounds like a good course of action? We could just do the second item for now, since it has a smaller scope and potential cone of destruction.

[Pilchie]

I suspect that the BuildingProject is always false for full framework projects today. dotnet/msbuild#2417 is only an issue for CPS projects AFAIK.

[cdmihai]

I suspect that the BuildingProject is always false for full framework projects today. dotnet/msbuild#2417 is only an issue for CPS projects AFAIK.

If it's setting it to false then it's hard to explain why the cache file appears. I tried looking at the design time log, but for some reason I don't get DT logs for classic projects, just core ones.

[Pilchie]

There are different ways to get design time logs for the old project system - see https://github.com/dotnet/project-system/blob/master/docs/design-time-builds.md

[davkean]

BuildingProject is always set to false for legacy project system. That won't be the reason the cache is not/or not appearing.

[cdmihai]

So, I looked further into this. As far as the common targets are concerned, the state file does not appear because BuildingProject is false (here and here). This happens for both the new and legacy project systems, I verified this via DTB logs (info bellow).

Whatever is causing DTBs on the legacy project system to write to a state file is not coming from Microsoft.Common.CurrentVersion.targets. The state file in the common targets is called either DesignTimeResolveAssemblyReferences.cache or ResolveAssemblyReference.cache. However, the file that actually appears on disk is called DesignTimeResolveAssemblyReferencesInput.cache. Searching for this string under the VS installation or under the MSBuild repo found nothing.

Core Project DTB binlog: NoStateFileOnCoreRar.zip
Classic Project DTB binlog: NoStateFileOnClassicRar.zip
Classic Project DTB txt log via TRACEDESIGNTIME: ClassicConsoleSetTraceDesignTime.log

These are all the DTBs that I get via the Project System Tools extension or by setting TRACEDESIGNTIME. None of them pass a state file to RAR. I also attached to devenv and put a breakpoint in RAR with the same finding, no state file provided.

Leads still to follow which I hope somebody with more VS experience can answer / help me look into:

• maybe there's some out of proc VS build server that invokes MSBuild?
• maybe the c++ code does weird things like directly calling into RAR? (and miraculously mocking everything else)
• maybe the cache file name is misleading and has nothing to do with RAR?

Whatever happens, there's no log that I can find to show it happening.

[davkean]

I wonder if if it's caused by: http://index/?query=ProjectShim&rightProject=Microsoft.VisualStudio.CommonIDE&file=ToolLocationHelperShim.cs&line=1187