Проект установщика VS 2010 не содержит общих ссылочных сборок для всех выходов

Я настраиваю проект установщика для решения C # и сталкиваюсь с проблемой зависимости:

В моем решении у меня есть 4 независимых выхода проекта - одна служба Windows и три исполняемых файла, которые все разделяют между собой некоторые ссылки.

Мне нужен установщик, чтобы установить все четыре из них, чтобы решение работало.

Я создал папку установки для каждого вывода проекта в разделе «Папка приложения» в диалоговом окне «Файловая система на целевой машине», успешно добавил вывод проекта службы Windows в свою папку. Но когда я продолжаю пытаться добавлять выходы проекта исполняемых файлов в их папки, сборки, уже перенесенные в папку службы Windows, не переносятся в папку исполняемых файлов, и после установки исполняемые файлы не будут запускаться, поскольку у них отсутствуют зависимости.

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

Любые идеи?


installation visual-studio-2010 .net c# installation-package
person Eliaz    schedule 06.03.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Что ж, вы должны создать новый проект в решении и установить «установщик» как выход вашего основного приложения (или основных приложений), он должен сам решать зависимости.

person squelos    schedule 06.03.2012
comment
Извините, но я ничего из вышеперечисленного не понял. Какой новый проект мне нужно создать в решении и с какой целью? что вы имеете в виду, когда устанавливаете программу установки как выходную часть основного приложения (приложений)? пожалуйста, попробуйте уточнить. Спасибо. - person Eliaz; 11.03.2012
comment
Да, в настройке должен быть установлен вывод для любого приложения, которое вы хотите развернуть. Ссылки должны решаться сами по себе, а в свойствах вы должны иметь возможность определять, каким образом сборки развертываются. Но я действительно не уверен, говорим ли мы об одном и том же. - person squelos; 11.03.2012

arrow_upward
1
arrow_downward

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

И приложение Winform, и консольное приложение используют одни и те же две внешние сборки: одна не является частью решения (ссылка на файл в папке), а другая - из проекта класса C # (ссылка на проект).

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

Неважно, создаете ли вы подпапки в папке приложения, Visual Studio, похоже, рассматривает папку приложения как единое целое ... что касается вывода проекта (exe, dll и res).

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

Если вы хотите сохранить все в одной установке, лучшим вариантом является использование GAC для общих сборок, что описано в другой статье о переполнении стека здесь: Используйте проект установки Visual Studio для автоматической регистрации и GAC библиотеки DLL COM Interop

MSI может выполнить свою работу. Щелкните правой кнопкой мыши «Файловая система на целевой машине», «Добавить», «GAC». Щелкните правой кнопкой мыши добавленную папку, «Добавить», «Вывод проекта». Это гарантирует, что сборка закрыта.

На мой взгляд, GAC - лучшее решение, потому что ваши сборки управляются уровнем .NET, если вы позже внесете в них изменения и улучшения. Одним из преимуществ .NET является устранение старых проблем, связанных с «адом DLL», которые были в Win 98 и предыдущих версиях Windows. Я настоятельно рекомендую использовать его для вашего общего кода.

person John J Schultz    schedule 15.07.2012