-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FUTDC doesn't check packed items when GeneratePackageOnBuild is true #9433
Comments
Looks like another case of #9001 |
I think this is unrelated to Build Acceleration. With project: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<ItemGroup>
<Content Include="build/Task.props" Pack="true" PackagePath="build/" />
</ItemGroup>
</Project> Enabling verbose FUTDC logs and building a few times shows:
The |
The SDK defines the Ideally we would condition this on the presence of the Lines 21 to 22 in c69d9b1
I cannot think of a better way than always calling this target unconditionally before |
Fixed in #9437 With those changes:
Specifically,
|
Verifying this behavior in the latest int.main and it appears the up-to-date might be broken in the other direction (i.e. unnecessary incremental builds). Using the same sample project from the original repo, here's the set of actions I took, what I expected to happen, and what actually happened
It seems like when the only reason for the build is a Pack item, the input to output stamp logic is getting messed up. Do something that causes the assembly to be newer than the pack item (step 6 in this case) fixes the issue. I'm also getting the following FUTDC warning, which may be related:
|
Re-opening. We will need to track the package output file as well, and isolate package inputs/outputs separately (probably via FUTDC "sets"). The challenge here will be knowing when |
Issue Description
When including content files in a NuGet package built with
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
, if only the content files change, Visual Studio considers the build up to date and doesn't create a new .nupkg, which breaks incremental build.Workaround
dotnet build
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
in the .csprojSteps to Reproduce
build/Task.props
(content doesn't matter)Expected Behavior
Actual Behavior
dotnet / Visual Studio info
dotnet: 8.0.202
Microsoft Visual Studio Enterprise 2022
Version 17.9.3
VisualStudio.17.Release/17.9.3+34701.34
Microsoft .NET Framework
Version 4.8.09032
Installed Version: Enterprise
The text was updated successfully, but these errors were encountered: