Развертывание приложения, охватывающего несколько папок .... почти <probing>

Question

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

Я хотел бы попытаться внести некоторую структуру в вещи при развертывании. Я думал так:

• c: \ program files \ MyCompany \ MyBigSystem \ App1
• c: \ program files \ MyCompany \ MyBigSystem \ App2
• c: \ program files \ MyCompany \ MyBigSystem \ App3
• c: \ program files \ MyCompany \ MyBigSystem \ AppN
• c: \ program files \ MyCompany \ MyBigSystem \ Core

Файлы в напр. ... \ App1, несомненно, будет иметь зависимые файлы в ... \ Core, но, очевидно, я хочу избежать перераспределения этих файлов в папку ... \ App1. Я хочу, чтобы App1 забрал их из папки Core.

Я изо всех сил пытаюсь понять, возможно ли это.

Вот некоторые ограничения и наблюдения:

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

Однако я могу использовать записи app.config, потому что они могут быть записаны во время установки.

Я посмотрел (и очень кратко протестировал) , который на первый взгляд казался идеальным, но в итоге оказался неподходящим из-за ограничения в качестве подкаталога

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

Кто-нибудь может предложить другой подход, который я мог бы рассмотреть?

TIA, Пит

Answer 1

Если вы используете Eclipse, вы можете создать проект для Core в качестве исходной библиотеки и включить его во все остальные ваши проекты.

Answer 2

В итоге я получил почти то, что хотел, но не совсем.Я получил всю необходимую структуру папок ....

• c: \ program files \ MyCompany \ MyBigSystem \ App1
• c: \ program files \ MyCompany \ MyBigSystem\ App2
• c: \ program files \ MyCompany \ MyBigSystem \ App3
• c: \ program files \ MyCompany \ MyBigSystem \ AppN
• c: \ программные файлы \ MyCompany \MyBigSystem \ Core

.... но пришлось поместить основные исполняемые файлы в папку «MyBigSystem», т.е.

• c: \ program files \ MyCompany \ MyBigSystem \App1.exe
• c: \ program files \ MyCompany \ MyBigSystem \ App1.exe.config
• c: \ программные файлы \ MyCompany \ MyBigSystem \ App2.exe
• c: \ program files \ MyCompany \ MyBigSystem \ App2.exe.config

Я дополнил эту структуру <probing> записями в конфигурационных файлах исполняемых файлов, например

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Core"/>
    </assemblyBinding>
  </runtime>

Thisказалось, что корневая папка была такой незагроможденной, на которую я мог разумно надеяться.Это также позволяет App6 получать доступ к зависимым библиотекам в App1, например, если это когда-либо понадобится.(Именно по этой причине я уклонялся от GAC - если когда-нибудь мы получим Приложения, зависящие от приложений, я вижу, что нам нужно GAC все, что было бы неуместно.)

В этом подходе нет изменений кодакроме как в конфигах.Основной проблемой стало заставить проект установки VS поместить все , кроме .exe и .exe.config в подпапку.

Answer 3

Вам, вероятно, придется компилировать, а не выпускать. Использовать сторонний установщик будет проще всего. Установить Щит это хорошо.