В проекте развертывания отсутствует зависимость проекта

Мне нужно добавить еще пару вещей после воспроизведения того же подозреваемого дефекта msi.

1) Когда я добавил второй вывод проекта, использующий ту же обнаруженную зависимость от установщика, он не добавлял зависимость автоматически. Я удалил оба вывода проекта и добавил их обратно в обратном порядке. Второй добавленный вывод проекта никогда не добавлял обнаруженную зависимость. Это исключает любые проблемы с конфигурацией или кодом для проектов и того, как были добавлены ссылки. Всегда терпит неудачу второй.

2) Моя команда фактически столкнулась со второй проблемой после использования обходного пути «Добавить обнаруженную сборку вручную». Первоначально мы добавили зависимость из местоположения в '\ Program Files \ xxx', но столкнулись с проблемами сборки на 64-битных машинах, где такая же зависимость находилась в папке '\ Program Files (x86) \ xxx', хотя VS достаточно умен, чтобы справиться с этой проблемой при подборе референсов.

• Правильный способ добавить сборку вручную - перейти в папку bin и добавить сборку, которая копируется локально. Это гарантирует, что нужная сборка будет присутствовать на машинах x86 или x64.

Я могу убедиться, что это проблема и для нас. Я подозреваю, что это ошибка в проекте развертывания - он добавляет только зависимые выходные данные проекта в одном месте (может быть, он думает, что это COM-DLL?)

Ручное добавление первичного вывода для отсутствующей библиотеки dll кажется жизнеспособным решением.

Я еще не использовал Visual Studio 2008, однако в 2005 году вы должны убедиться, что для отсутствующей ссылки в проекте для свойства Copy Local установлено значение true.

Это скопирует отсутствующий файл в выходной каталог.

В дополнение к ответу hectorsq убедитесь, что зависимость находится в списке зависимостей проекта развертывания и что соответствующая DLL помечена для включения.

Вы пробовали смотреть на свою dll в отражателе, чтобы узнать, действительно ли она зависит от другой dll? VS достаточно умен, чтобы не включать сборку, на которую указывает ссылка, если видит, что вы на самом деле ее не используете.

К тому же, даже если вы «думаете», что используете его, VS может оптимизировать ваше использование - это предельный случай, но я это видел:

Например, если у вас есть сборка констант с этим в:

public const string LockPanelUrn = "ApplicationRack.LockPanel";

VS вставит строку прямо в ссылочный код.

Кроме того, я предлагаю удалить и перестроить ваше решение для установки.

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

проверьте это - возможно, это не объясняет, почему это так, но, по крайней мере, это дает какое-то обходное решение :)

http://lo-sharpdevs.blogspot.com/2009/07/vs-2008-disappearing-dependencies.html

У меня была аналогичная проблема с использованием объектов Microsoft SMO. У меня есть двоичный компонент (X.dll), который использует эти объекты Microsoft SMO, которые я сделал сам. После компиляции X.dll я ссылаюсь на него в другом проекте EXE, используя X.dll (а не код). Присоединенный к нему проект установщика определяет, что ему нужны объекты Microsoft SMO, и обнаруживает, что они являются локальными для моей установки SQL Server на машине.

Компонент X.dll, который использует объекты SMO, ссылается на объекты Microsoft SMO через локальную папку «Externals», которую я храню на общем диске. Все модули скомпилированы со ссылкой на них, однако мой проект установки с моим проектом EXE обнаруживает модули из моей установки SQL Server.

Из-за этого у нас есть другой компьютер, на котором есть папка «Внешние» с объектами SMO, но проект установки больше не будет находить объекты SMO из «Обнаруженных зависимостей», так как он не понимает, что объекты SMO находятся во внешнем модуле! Я не уверен, где он ищет файлы обнаруженных зависимостей, но он не смотрит на то, откуда X.dll их изначально взял, или даже на папку EXE, возможно ...