search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.22k stars 1.35k forks source link

Analyzer for "bad" AssemblySearchPaths #10368

Open KirillOsenkov opened 3 months ago

KirillOsenkov commented 3 months ago

AssemblySearchPaths should just be {RawFileName};{HintPathFromItem};{TargetFrameworkDirectory}

Many builds still have {GAC}, registry and other such nonsense. We should consider an analyzer that recommends turning off the "bad" ones and only leave the above three. It might of course reveal cases where people accidentally depend on the bad ones, but maybe trying to turn them off one by one will lead people towards improving their builds.

.NET SDK already defaults to the three good ones plus CandidateAssemblyFiles. CandidateAssemblyFiles is bad, I sometimes see someone include a .dll as Content, and it ends up being an input to RAR, unintentionally. So most newer projects should be in good-ish shape.

See related: https://github.com/dotnet/msbuild/issues/3784

Thankfully we now have properties to individually turn off each of those: https://github.com/dotnet/msbuild/pull/7008

baronfel commented 3 months ago

@MattKotsenas this would be a good analyzer for dotnet/reproducible-builds. @KirillOsenkov perhaps a bit restrictive for MSBuild itself?

KirillOsenkov commented 3 months ago

if it's informational, I think it'd be very useful. Certainly not an error or a warning. I stipulate that every usage of those bad search paths is wrong and needs to be corrected. Files need to resolve either from NuGet, project references or target framework. Resolving from GAC, OutDir, registry, etc. is bad bad bad.

rainersigwald commented 3 months ago

Strong agree on GAC, registry, and AssemblyFoldersEx; OutDir I agree is bad but I think would be over a line where a bunch of customers do it so I'd be more cautious.