Блог

У нас проблема с файлами нашего проекта, что раздражает.

Пример:

У нас есть решение с ProjX и projY, которые ссылаются на сборку log4net.

Скажем, например, кто-то перемещает файл сборки и обновляет ссылку только в ProjX затем фиксирует, не обнаруживая отсутствующую сборку — тогда ссылка пропадает в projY.

В следующий раз, когда я выполню проверку и открою решение, у projY будет ссылка, правильно помеченная VS2010 как отсутствующая, с небольшим восклицательным знаком. Пока все хорошо. 🙂

Проблема:

Теперь, если я выполняю сборку решения, тогда ссылка на сборку волшебным образом обновляется в projY, чтобы указывать на папку BIN ProjX в,,, ProjX! (В этом случае ProjX должен быть собран ДО projY)

Похоже, что VS2010 выполняет поиск в нашем дереве решений и автоматически добавляет сборку, если может найти подходящую.

Приятная функция, но также немного опасная и очень вводящая в заблуждение. Например, сборка может в конечном итоге иметь путь, который указывает на другую папку projects bin.

Вопрос:

Есть ли какой-нибудь способ отключить это поведение и просто получить ошибку компиляции, которая предотвращает сборку?

Примечания:

• Недавно мы перешли на использование NuGet.
• Мы определили нашу собственную папку вывода -> файлы помещаются не в Bin Debug, а в ..вывод.

[ПРАВИТЬ]

Обновил пример для большей наглядности.

[ПРАВИТЬ]

В поисках решения в Интернете я нашел эту статью, в которой описывается связанная проблема, где VS2010 также автоматически добавляет ссылки, но в данном случае из GAC. Наших сборок НЕТ в GAC. http://blog.scrappydog.com/2010/07/bug-tfs-2010-outsmarts-itself-and-auto.html

[ПРАВИТЬ]

Пытался исправить это, используя ссылочный путь в проекте. Идея заключалась в том, что VS сначала выполнит поиск по ссылочному пути, а затем по папкам проекта bin. Но безуспешно. Он по-прежнему берет сборки из выходной папки.

Нет, известного обходного пути по этому поводу не существует.

Я знаю, это может показаться глупым, но вы проверили ссылочные пути ваших проектов, определенные в свойствах проекта? Возможно, это просто получение недостающей ссылки из любых путей, которые вы, возможно, настроили.

У меня была такая же проблема с одной сборкой.

Что сработало для меня, так это фактически переместить всю папку решения в корень диска, поскольку путь к некоторым файлам превышал 256 символов. Я узнал это при попытке заархивировать / разархивировать папку с решением.

Вы подтвердили это в других сборках? Я раньше не использовал log4net, но если он находится в глобальном кэше сборок (GAC) с правильной версией, его можно получить оттуда. GAC — это место, куда отправляются общесистемные сборки, на которые ссылаются приложения в системе.