An API to locate MSBuild assemblies from an installed Visual Studio location. Use this to ensure that calling the MSBuild API will use the same toolset that a build from Visual Studio or msbuild.exe would.
Other
220
stars
83
forks
source link
Can we avoid binding redirects since Locator controls binding? #83
Currently Locator pushes MSBuild binding redirects into the app.config of the app that references it.
MSBuild requires assembly unification because a new version of MSBuild must be able to run tasks compiled against an older MSBuild, so we must unify to the engine's version of ITask and ITaskItem and so on.
However, MSBuildLocator is in charge of loading MSBuild assemblies, and can do some unification itself. Is that sufficient to drop the need to have app.config binding redirects for client applications?
If this worked, we could more freely rev MSBuild's assembly version, since we'd be binding by location rather than version.
@andygerlicher, was talking about this with @nguerrera and we both have a vague recollection that this wouldn't be enough, but no idea why. Do you remember anything?
Currently Locator pushes MSBuild binding redirects into the
app.config
of the app that references it.MSBuild requires assembly unification because a new version of MSBuild must be able to run tasks compiled against an older MSBuild, so we must unify to the engine's version of
ITask
andITaskItem
and so on.However, MSBuildLocator is in charge of loading MSBuild assemblies, and can do some unification itself. Is that sufficient to drop the need to have
app.config
binding redirects for client applications?If this worked, we could more freely rev MSBuild's assembly version, since we'd be binding by location rather than version.