Пакет Azure содержит неверную DLL

Question

В своих веб-ролях и рабочих ролях я ссылаюсь на альтернативную версию базовой библиотеки DLL.Файл помечен Copy Local.Visual Studio показывает правильную версию в качестве ссылки на проект.При компиляции проекта каталог bin также содержит правильную версию.

Однако, когда я прошу Visual Studio создать пакет Azure, пакет (и папка csx, созданная во время упаковки) содержитнеправильная (оригинальная) DLL только для рабочей роли.Веб-роль имеет правильную DLL.Этого не происходит, если я вручную использую cspack, но это не совсем желательный способ упаковки.

Что может заставить Visual Studio скомпилировать правильную эталонную DLL, но связать неверную?

Дополнительная информация: Когда я запускаю msbuild для создания упаковки вместо Visual Studio, я вижу следующие две строки:

Copying file from "C:\Users\bytenik\Dropbox\Treadmarks\lib\EntityFramework\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
Copying file from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".

Итак, похоже, что я скопировал мою ссылку, а затем скопируйте его с системной ссылкой.

Примечание: Я хорошо знаю, что сама идея замены DLL-библиотеки .NET CLR - это огромный взлом.Когда выйдет .NET 4.5 с поддержкой нужной мне функции, все это будет удалено.Тем временем мне нужно иметь возможность продолжить разработку.

Это замена вопроса " Ссылки Azure неверная DLL ", который на самом деле был некорректным и приводил к ответам.которые были действительны, но не решили мою проблему.

Answer 1

Даже если проект Visual Studio имеет ссылку на локальную и / или измененную копию сборки, которая находится в GAC, она будет использоваться во время компиляции, но во время выполнения CLR всегда будет загружать сборку изGAC, даже если он находится прямо в том же каталоге, что и ваше приложение.

Таким образом, решение заключается не в том, чтобы найти умный способ упаковать или развернуть измененную сборку, а в том, чтобы найти способ сделатьCLR фактически загружает его, если он там есть.

Два возможных решения:

1) Используйте задачу запуска роли и проект установки для развертывания измененной версии сборки в GAC производственного сервера.

2) Удалите подпись сборки и убедитесь, что все ссылки сделаны на эту версию без подписи.Остерегайтесь других сборок, которые могут ссылаться на оригинальную подписанную версию и попытаться загрузить ее из GAC.

Для получения дополнительной информации и ссылок см. Как запретить приложению .NET использовать сборку из GAC