Ссылка.NET “Копирует Локальный” Верный / Ложь, Устанавливаемая На основе Содержания GAC
У нас была очень интересная проблема с проектом Форм Победы. Это было разрешено. Мы знаем то, что произошло, но мы хотим понять, почему это произошло. Это может выручить других людей в будущем, у которых есть подобная проблема.
Проект WinForms перестал работать на 2 из ПК нашего клиента. Ошибка была неясной ошибкой kernel.dll. Проект хорошо работал на 3 других ПК.
Мы нашли, что.DLL (log4net.dll - очень популярная библиотека входа открытого исходного кода) отсутствовал в нашей папке выпуска. Это было ранее в нашей папке выпуска. Почему это отсутствовало в этом последнем выпуске?
Это отсутствовало, потому что я, должно быть, установил программу на своем поле Dev, которое использовало log4net.dll, и это было добавлено к Глобальному кэшу сборок.
Когда я проверил ссылки решения на log4net.dll, они были изменены для "копирования local=FALSE". Они, должно быть, изменились автоматически, потому что log4net.dll присутствовал в моем GAC.
Вот то, где мой вопрос запускается:
То, почему сделал мою ссылку для log4net.dll, изменяется из КОПИИ, ЛОКАЛЬНОЙ = TRUE для КОПИРОВАНИЯ ЛОКАЛЬНЫЙ = ЛОЖЬ? Я подозреваю, что это - потому что это было добавлено к моему GAC другой программой.
Как мы можем предотвратить это снова?как есть Теперь, если я устанавливаю часть программного обеспечения, которое пользуется общей библиотекой, и оно добавляет его к моему GAC, затем мой SLNs, что ссылка, что DLL изменит из Копии Локального TRUE ко ЛЖИ.
4 ответа
Это произошло потому, что нет никакого смысла в Copy Local = True, если сборка установлена в GAC. Поскольку эта локальная копия никогда не будет использоваться, поиск в GAC всегда выполняется первым. Если оставить это значение без изменений, то возникнет путаница, вы будете думать, что используете локальную копию, но вместо нее получите другую. Изменение этого параметра тоже вызывает путаницу, если вы его не заметите, что, возможно, можно было бы решить с помощью окна сообщения во время загрузки решения.
Log4net - нарушитель спокойствия, существует слишком много версий в природе без какой-либо процедуры развертывания, которая гарантирует, что эти версии не покусают друг друга. Что-то, что Apache, очевидно, просто не хочет решать, оставляя это на усмотрение программиста. Наличие продуктов, которые принимают зависимость от Log4net и делают что-то с предполагаемым риском DLL Hell, в некоторой степени неизбежно. Давая вам взамен проблему DLL Hell.
Нет простых ответов, кроме осознания того, что установлено на вашей машине. Подумайте о том, чтобы написать на connect.microsoft.com просьбу о предупреждении, когда Visual Studio автоматически обновляет свойство Copy Local. Это разумная просьба.
Можете ли вы убедиться, что ваш путь используется, добавив hintpath в файл msbuild / proj?
По приведенной выше ссылке:
HintPath : относительный или абсолютный путь сборки.
Во время выполнения сборки должны находиться в одном из двух мест: путь вывода проекта или глобальный кеш сборок (см. Работа со сборками и глобальный Кэш сборки). Если проект содержит ссылку на объект, который не находится в одном из этих расположений, то при построении проекта ссылку необходимо скопировать в выходной путь проекта. Свойство CopyLocal указывает, нужно ли делать эту копию. Если значение истинно, ссылка копируется. Если false, ссылка не копируется.
Присвоенное проекту значение CopyLocal определяется в следующем порядке:
- Если ссылка представляет собой другой проект, называемый ссылкой проекта на проект, тогда значение истинно.
- Если сборка найдена в глобальном кэше сборок, значение равно false.
- В качестве особого случая ссылка на mscorlib.dll имеет значение false.
- Если сборка найдена в папке Framework SDK, тогда значение false. В противном случае значение true.
С уважением ... Muse VSExtensions
Я только что столкнулся с этой проблемой и на наших серверах сборки. Это очень раздражающее (и неожиданное) поведение Visual Studio. Два пути решения:
- Удалить сборки из GAC.
- Добавить событие PostBuild для ручного копирования сборок в выходной каталог.