Add StringTools to do-not-deploy list #354
Conversation
An internal tool recently had trouble updating to .NET 10 because it deployed a stale local copy of `Microsoft.NET.StringTools.dll` that was working (by coincidence) throughout .NET 9 but failed after dotnet/msbuild#12100 added some API surface to StringTools and used it.
| '%(PackageReference.Identity)' == 'Microsoft.Build.Engine' | ||
| '%(PackageReference.Identity)' == 'Microsoft.Build.Engine' or | ||
| '%(PackageReference.Identity)' == 'Microsoft.NET.StringTools' or | ||
| '%(PackageReference.Identity)' == 'NuGet.Frameworks' |
There was a problem hiding this comment.
Curious: any way that you could think of to write a test that captures the list of "do not deploy DLLs"? Struggled with this in Roslyn a few times. Eventually we found a few tests we could write where we maintained a string[] in the test of dependencies, when the test failed there was a comment of "if you update this list, go update this other file". It was far far from perfect but was an easy spot check for us.
Not sure if that is easy / not here.
There was a problem hiding this comment.
I can't think of a particularly good way, unfortunately. This list is definitely not complete, but I'm not 100% sure how complete it can be without causing problems for users. Like, can we put System.Collections.Immutable on here? Ideally we would!
4 participants
An internal tool recently had trouble updating to .NET 10 because
it deployed a stale local copy of
Microsoft.NET.StringTools.dllthatwas working (by coincidence) throughout .NET 9 but failed after
dotnet/msbuild#12100 added some API surface to StringTools and used it.
Partial fix for #353.