Visual Studio continually rebuilds container

[afscrome]

If I have <EnableSdkContainerDebugging>True</EnableSdkContainerDebugging> enabled in my project, then Visual Studio continually rebuilds my project's container, even when there are no changes to the project and I'm not actually running my project . This is adding ~20-30 seconds onto every time Visual studio builds the project, adding a lot of lag into the inner loop.

e.g. I'm working on an Aspire App Host which references the project that is marked as EnableSdkContainerDebugging. Even though I'm not changing the containerized project, every time I build the app host. Similar happens if I'm running unit tests in a test project that itself references my containerized project.

I'd expect Visual Studio to only build the image if I try to run/debug the image, and for the build process to be aware of Incremental builds, and only build if something has actually changed.

[baronfel]

The CLI won't trigger the containerization process unless you run 'dotnet publish', so I have to imagine there's some overbuilding or something happening on the VS Tooling side. @danegsta can you help with who should dig in to this?

Separately, we are working on incrementality improvements to the container publishing all-up for .Net 10. It's been quite fruitful - the whole process is almost embarrassingly incremental.

[afscrome]

I have a binlog if it helps. From what I can tell, VS sets SdkContainerPublishOnBuild as a global property,

Which is then picked up by C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Microsoft.Common.targets\ImportAfter\Containers.Tools.targets to explicitly call the PublishContainer target.

<Project>
    <ItemGroup>
        <ProjectCapability Condition="'$(EnableSdkContainerDebugging)' == 'true'" Include="SdkContainerDebugging" />
    </ItemGroup>
    <ItemGroup Condition="'$(EnableSdkContainerDebugging)' == 'true' AND '$(BuildingInsideVisualStudio)' == 'true' AND '$(DockerIncludeDefaultImageLabels)' != 'false' AND '$(ContainerIncludeDefaultImageLabels)' != 'false'">
        <ContainerLabel Include="com.microsoft.created-by" Value="visual-studio"/>
        <ContainerLabel Include="com.microsoft.visual-studio.project-name" Value="$(MSBuildProjectName)"/>
    </ItemGroup>
    <Target Name="CallPublishContainerSdkContainerProfile" AfterTargets="Build" Condition="'$(EnableSdkContainerDebugging)' == 'true' AND '$(SdkContainerPublishOnBuild)' == 'true'" DependsOnTargets="Publish;PublishContainer"/>
</Project>

Look forward to the wider incrementality improvements!

[danegsta]

I'm suspicious the main issue is that we aren't considering the purpose of the build in VS when we trigger publish; we're just naively doing a publish for every build regardless of whether the user is intending to do an F5/Ctrl+F5. I'll raise this with our team to see if we can consider whether we're just building or building to run and only do a publish on build in the latter case.

[afscrome]

Another thing that occurs to me - in our case, the SDK launch profile is a non default one, so even if debugging, the container publish target would ideally only be invoked if running /debugging the container launch profile. i.e. in the below case, the Console launch profile is being used, so even if running / debugging, the container publish would ideally not be invoked.