Skip to content
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

EmbeddedResource - prevent breaking change #11313

Open
JanKrivanek opened this issue Jan 20, 2025 · 0 comments · May be fixed by #11320 or #11298
Open

EmbeddedResource - prevent breaking change #11313

JanKrivanek opened this issue Jan 20, 2025 · 0 comments · May be fixed by #11320 or #11298
Assignees
Labels

Comments

@JanKrivanek
Copy link
Member

Context

tl;dr;: preserving the previous behavior, and hidden the improvemnet behind opt-in

The newly added MSB3002 ('Explicitly set culture ... was overwritten') is a diagnostic informing about a real problem but it has a potential of breaking a build with esoteric conditions where users might not care about their build behaving wrong.

This was e.g. case solved as part #11091 - where a custom injected target was postprocessing WithCulture metadata after AssignCulture task run. The newly added beahvior broke the task (while adding RespectAlreadyAssignedItemCulture fixed the case - it needed an action from the build owner).

Another case was breakage in dotnet/sdk#45880 - where the test explicitly counted on failing on 'error MSB3030: Could not copy the file "<...>.resources.dll" because it was not found.', while the new behavior lead to success build with warning.

While both cases are quite edgy - it shows the change has potential to break.

Suggestion

Hide the improved behavior behind explicit opt-in

The other options:

  • Leave it as opt-out, with warning, while behavior unchanges (the explicit Culture metadata would be overwritten by extension derived culture)
  • Leave it as opt-out without warning, while changing beahivor (explicit Culture metada would be always respectd)

Those two are not recommended as they have higher potential of back compat breakages

@JanKrivanek JanKrivanek self-assigned this Jan 20, 2025
@JanKrivanek JanKrivanek linked a pull request Jan 20, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
1 participant