VS FUTDC is not considering updates to file-based resources

softworkz commented 5 months ago

Visual Studio Version

17.9.5

Summary

I'm not 100% sure but I didn't experience such issues before "Build Acceleration" was switched on by default (too hastily IMO!!!!).

I have projects with file-sourced RESX resources. When changing those files (and no other change), the project doesn't get built (or at least the resources aren't rebuilt), which means that when starting a consuming project for debugging, the dependency project doesn't have the updated resources.

Steps to Reproduce

Create C# class library project (netstandard2.0 in my current case)
Add text file (build action "None")
Add RESX resources
Open RESX designer
Switch to "Files" (dropdown at left top)
Drag-Drop the text file into the designer
Select the file in the designer and change type to "Binary" (just because that's what I do, unlikely that it's needed)
Add aother project: E.g. WinUI3 EXE, packaged (again, for the sake of doing equal things)
Add a reference to the first project
Add some code to the exe projecft to read the resource from the first project

Once it works, change the contents of the text file and start debugging again.

Expected Behavior

The first project is recompiled to include the updated resources and the exe project can "see" the updated content.

Actual Behavior

Dependency projects often don't get rebuilt. especially when that kind of change is the only change made.

User Impact

Severe. It is crucial in sw development to be able to rely on the tooling you are using. This needs to work rock-solid, otherwise it is wasting time of hundred-thousands of users.

Looking at all the issues, it appears to me that this new change doesn't meet that bar.

The advantages are great, but you cannot roll out such a half-baked feature as default-on.

The sole fact that you are trying to get around the shortcomings of this implementation by "blacklisting" cases where it doesn't work, is a strong indication that there exists an inherent conceptual flaw in the approach being taken.

-- Probably needs label: Feature-Build-Acceleration

drewnoakes commented 5 months ago

Thanks for the detailed repro steps.

I don't believe build acceleration is involved here. In fact I doubt the scenario you're describing has ever worked, as the fast up-to-date check isn't aware of files that are linked into .resx files.

Please verify whether disabling build acceleration makes a difference. If so, please turn on verbose FUTDC logging and share your findings.

softworkz commented 5 months ago

Regarding " I doubt the scenario you're describing has ever worked,", here's proof that the opposite is true:

ResxUpdateTest.zip

I created this in VS 2019, to be sure that none of the latest changes get into play. FUTD check existed in VS 16 (and long before).

Set WindowsFormsApp1 as the startup project and run.

Then update the text file in the ClassLibrary1 project and hit debug again and you'll see your updated text.

After zipping, I noticed that the build action for the file is "Content". But it's still working when you set it to "None".

drewnoakes commented 5 months ago

Did you try disabling build acceleration? I'll take a look locally to see if I can understand more about what's going on.

softworkz commented 5 months ago

It's a complex solution, so I don' have a definite reliable answer, but here's what I tried:

Set Feature-Flag to false => no change
Add <AccelerateBuildsInVisualStudio>false</AccelerateBuildsInVisualStudio> to a common props file => no change
Change (resource-source) file property "CopyToOutputDirectory" to "Copy if newer" => working!
Revert Feature-Flag and remove the MSBuild property => not working

In-betwen each of those steps, I have closed VS, deleted all bin and obj folders and the .vs folder and restarted VS

drewnoakes commented 5 months ago

Regarding " I doubt the scenario you're describing has ever worked,", here's proof that the opposite is true

I see the confusion here. That ZIP contains legacy (.NET Framework-era) projects, not SDK-style projects.

This repo contains the SDK-style project system, which uses a different FUTDC. The legacy project system is owned by a different team. It's an internal codebase with an internal issue tracker.

I assume you're experiencing an issue with an SDK-style project, given you mention netstandard2.0. If not, please file a new issue on developer community, so that it can be routed to the correct team. If you link it here, I'll ensure it gets in front of the right people.

I've validated the behaviour in VS2022 and VS2019, with and without Build Acceleration, and the problem has always existed for SDK-style projects.

This is unrelated to Build Acceleration. The FUTDC doesn't check None items, as there can be lots of those in a project, and checking them all kills build performance.

So there is a bug here, but it's more straightforward than what's explained above. I've filed https://github.com/dotnet/project-system/issues/9441 to track it. Please review that issue to ensure it reflects the problem you're seeing to your satisfaction. You can

softworkz commented 5 months ago

Regarding " I doubt the scenario you're describing has ever worked,", here's proof that the opposite is true

I see the confusion here. That ZIP contains legacy (.NET Framework-era) projects, not SDK-style projects.

LOL, I'm not confused, I just wanted to give an example that this has "ever worked" as I've been using it often enough.

I've used this in SDK style projects as well, but not with frequent updates of the content, so here I might have been "lucky" in a way that I didn't notice it.

So there is a bug here, but it's more straightforward than what's explained above. I've filed https://github.com/dotnet/project-system/issues/9441 to track it. Please review that issue to ensure it reflects the problem you're seeing to your satisfaction

Thank you, looks good to me.

Yet there's still the reported discrepancy:

When I set "Copy if newer" for the file in question, I get the desired behaviour (resx resources get updated).

But only when "Build Acceleration" is disabled, not when it's enabled. BA copies the file to the output, but the resources aren't re-generated.

drewnoakes commented 5 months ago

When I set "Copy if newer" for the file in question, I get the desired behaviour (resx resources get updated).

That flags the file as needing to be copied, which then triggers a build. However if you enable BA then VS does the copy. That's expected. The core of the issue is that the FUTDC doesn't see the input files to the .resx files in the project, which is what the linked issue is tracking.

softworkz commented 5 months ago

Interestingly, this can be worked around by setting the build action of the resource input file to "Resource". That build action effectively doesn't do anything (for non-WPF projects like I have), but it fixes the problem, even with BA enabled.

softworkz commented 5 months ago

But most importantly: Thank you very much for the quick and professional response! ⭐ (both aspects getting rare these days..)

drewnoakes commented 5 months ago

Interestingly, this can be worked around by setting the build action of the resource input file to "Resource".

Resource items are tracked by build. A core part of the issue here is the None item. There can be many of those and they're not included by default in the FUTDC. The FUTDC's time is mostly spent scanning timestamps on disk.

softworkz commented 5 months ago

Yeah, the idea for working around was to find something which includes the files in the build without doing anything to them, since I really don't want to have them in the output. So, this appears to serve well as temporary workaround.

BTW, the dissatisfaction that I expressed in the OP wasn't focused on this issue alone. I've been struggling for quite a while with project reference outputs not being copied (Ino matter which properties are set on the reference). But few weeks ago, it stopped happening in the same silent and unexpected way like it had started, so there's no point in warming this up, seems to be good again. Yet I wish there wouldn't be so many different teams, each cooking their own soup. Quality of tooling is still ok, but not at the level it's been at earlier times, and that was the background of my initial statements. Thanks again!

drewnoakes commented 5 months ago

Another way to tell the FUTDC to track extra files is via UpToDateCheckInput items.

softworkz commented 5 months ago

Another way to tell the FUTDC to track extra files is via UpToDateCheckInput items.

Which can't be set or seen in the UI... Anyway those are just workarounds. It's something that needs to work out of the box. Especially FUTDC should provide equal behavior to MSBuild alone. It shouldn't be something one needs to care about at all.

dotnet / project-system