Комментарии 13
Указание всем сборкам одной и той же версии независимо от содержания представляется мне каким-то мрачным костылем. Который, возможно, решил когда-то какую-то частную проблему, зато обеспечил огромное кол-во гемороя на годы вперед...
Майкрософт вообще любит костыли. Вспомнился старый пост про х64… Логика там конечно примерно такая же: https://habr.com/ru/post/102179/
Я тоже так подумал) Но maintainer MSBuild-а вроде достаточно уверено говорил, что это удобно и всё такое.
Как говорилось в одном классическом тексте,
Let’s be very, very clear about one thing: .NET will eliminate DLL Hell.
Ужас какой. А как тогда разные "версии" этой библиотеки ставятяся, если номер версии один и тот же? Какой-то другой идентификатор есть?
Нужно просто резолвиться самостоятельно )
internal static class Program
{
private static void Main(string[] args)
{
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
}
private static System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs e)
{
if (e.Name.StartsWith("Microsoft.Build."))
{
// искать в локальной папке
}
return null;
}
}
А вы действительно пробовали этот способ? Указанное вами событие, согласно документации, возникает, когда сборку загрузить не получилось.
А в указанном в статье случае она прекрасно загружается :).
Мы пробовали даже просто в начале Main загрузить сборку с указанием прямо конкретного пути, но она всё равно берётся из GAC.
Зачем при изменении сборки менять её версию или как сломать Visual Studio одной командой