You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 afterAssignCulture
task run. The newly added beahvior broke the task (while addingRespectAlreadyAssignedItemCulture
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:
Culture
metadata would be overwritten by extension derived culture)Culture
metada would be always respectd)Those two are not recommended as they have higher potential of back compat breakages
The text was updated successfully, but these errors were encountered: