Improved incremental build/reference assembly support

(This was reported to me offline via email; I’m adding some context.)

MSBuild and the Roslyn compilers use a feature called reference assemblies to attempt to minimize the build impact of changes to referenced assemblies. When the internal implementation of an assembly changes without changes to its public API surface, referencing projects shouldn’t need to rebuild. This feature is turned on by default for projects targeting .NET 5.0+.

This isn’t working for WPF projects, though. As an example, take a small solution with two projects: a library and a WPF app that references the library. Change whitespace in the library and build the solution. Ideally, the library would recompile, the WPF app would not, and the library would just be copied to the output folder of the WPF app.

In the current implementation, the WPF app is always rebuilt. The proximate cause is

Target Name=CoreCompile Project=WpfApp.csproj
    Building target "CoreCompile" completely.
    Output file "obj\Debug\net5.0-windows\WpfApp.dll" does not exist.

That’s happening in

Target Name=CleanupTemporaryTargetAssembly Project=WpfApp.csproj
    Task "Message" skipped, due to false condition; ('$(MSBuildTargetsVerbose)'=='true') was evaluated as (''=='true').
    Delete
    Delete
        Parameters
            Files = obj\Debug\net5.0-windows\WpfApp.dll
        Deleting file "obj\Debug\net5.0-windows\WpfApp.dll".
    Delete

That’s happening because the _wpftmp project builds to the same location.

The _wpftmp project builds because MarkupCompilePass1 tells it to:

_RequireMCPass2ForMainAssembly = True

It’s doing that because it is taking the implementation assembly as an input, through @(ReferencePath).

I think it could use @(ReferencePathWithRefAssemblies) like CoreCompile does.

[rainersigwald]

Fortunately I think I just hadn’t run the scenario I thought I had. Things seem to be working now with this change:

--- C:\Program Files\dotnet\sdk\5.0.401\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets
+++ private modification
@@ -215,13 +215,13 @@
   ================================================================
                                    MarkupCompilePass1
   ================================================================
   -->
 
   <Target Name="MarkupCompilePass1"
-          DependsOnTargets="$(MarkupCompilePass1DependsOn);SplashScreenValidation"
+          DependsOnTargets="$(MarkupCompilePass1DependsOn);SplashScreenValidation;FindReferenceAssembliesForReferences"
           Condition="'@(Page)' != '' or '@(ApplicationDefinition)' != '' " >
 
         <Message Text="(in) Page: '@(Page)'" Condition="'$(MSBuildTargetsVerbose)'=='true'"/>
         <Message Text="(in) ApplicationDefinition: '@(ApplicationDefinition)'" Condition="'$(MSBuildTargetsVerbose)'=='true'"/>
         <Message Text="(in) Resource: '@(Resource)'" Condition="'$(MSBuildTargetsVerbose)'=='true'"/>
         <Message Text="(in) CodeGenReference: '@(ReferencePath)'" Condition="'$(MSBuildTargetsVerbose)'=='true'"/>
@@ -246,13 +246,13 @@
                PageMarkup="@(Page)"
                ContentFiles="@(Content)"
                AssemblyName="$(AssemblyName)"
                OutputType="$(OutputType)"
                AssemblyVersion="$(AssemblyVersion)"
                AssemblyPublicKeyToken="$(AssemblyPublicKeyToken)"
-               References="@(ReferencePath)"
+               References="@(ReferencePathWithRefAssemblies)"
                RootNamespace="$(RootNamespace)"
                KnownReferencePaths="$(MSBuildBinPath);$(TargetFrameworkDirectory);@(_TargetFrameworkSDKDirectoryItem);@(KnownReferencePaths)"
                AssembliesGeneratedDuringBuild="@(AssembliesGeneratedDuringBuild)"
                AlwaysCompileMarkupFilesInSeparateDomain="$(AlwaysCompileMarkupFilesInSeparateDomain)"
                HostInBrowser="$(HostInBrowser)"
                LocalizationDirectivesToLocFile="$(LocalizationDirectivesToLocFile)"

I think this is too risky for 6.0 GA but it’d be a nice speedup for 6.0.200/VS 17.1 if we could get it . . .

[pchaurasia14]

@czdietrich - Unfortunately, we weren’t able to attend this item for the past releases. We’ll certainly target this for upcoming releases.