Отсутствие проекта в проекте развертывания

У меня есть проект развертывания VS2008, который создает установщик для нескольких служб Windows.

Каждая служба ссылается на несколько разных проектов:

CustomerName.MailSendingService
 -> CustomerName.Network
 -> CustomerName.Data
 -> CustomerName.Security

CustomerName.ProductIntegrationService
 -> CustomerName.Core
 -> CustomerName.Security

Проекты службы Windows, проекты, которые они ссылаются, и проект развертывания находятся в одном решении VS2008.

Я добавил основной вывод из проектов службы Windows в редакторе файловой системы проекта развертывания.

Я ожидаю, что основной вывод для проектов служб Windows будет включать библиотеки DLL из проектов, на которые ссылаются. Однако, когда проект развертывания построен, DLL из одного из указанных проектов отсутствует. (CustomerName.ProductIntegrationService отсутствует CustomerName.Security)

Поразительно, что библиотеки DLL для других проектов, на которые ссылается служба Windows, присутствуют; только один выход проекта отсутствует.

(Изменить) Я проверил, что для ссылки задано значение Копировать локальное в окне свойств ссылки. DLL для упомянутого проекта помещается в папку bin\Release в каталоге службы Windows, но не упакована в файл MSI, созданный для проекта развертывания.

(Edit 2) Следуя предложению Джозефа Дайгла, я проверил, что зависимость находится в списке зависимостей для первичного вывода, и он не помечен как "исключенный", поэтому это не является причиной этой проблемы.

Почему просто один проект не будет отсутствовать?

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

public const string LockPanelUrn = "ApplicationRack.LockPanel";

VS будет вставлять строку непосредственно в ваш ссылочный код.

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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