Как я работаю с совместно используемыми сборками и проектами?
Для снабжения предисловием я работал с C# в течение нескольких месяцев, но я абсолютно незнаком с понятиями как развертывание и блоки и т.д. Мои вопросы - многие и варьировались, хотя я неистово гуглю и читаю о них напрасно (у меня в настоящее время есть Pro C# 2008 и.NET 3.5 Платформы передо мной).
У нас есть этот процесс, и он состоит из трех компонентов: механизм, фильтр и логика для процесса. Мы любим этот процесс так сильно, мы хотим снова использованный в других проектах. Таким образом, теперь я начинаю исследовать пространство вне одного решения, одного проекта.
Это звучит корректным? Одно огромное Решение:
- Обработайте A, exe
- Обработайте B, exe
- Обработайте C, exe
- Фильтр, dll
- Механизм, dll
Механизм совместно используется код для всех процессов, таким образом, я предполагаю, что это может быть совместно используемой сборкой? Если совместно используемая сборка находится в том же решении как проект, который использует его, как это становится использованным, если это, как предполагается, находится в GAC? Я считал что-то о событии сборки сообщения. Это означает, что engine.dll должен быть reployed на каждой сборке?
Кроме того, принципиальная причина, мы разделили фильтр от процесса (только один процесс использует его) состоит в том так, чтобы мы могли развернуть фильтр независимо от процесса так, чтобы исполняемый файл процесса не должен был быть обновлен. Независимо от того, если это - лучшая практика, позвольте нам просто прокрутиться с нею. Действительно ли это возможно? Я считал, что блоки связываются с определенными версиями других блоков, поэтому если я обновляю DLL только, он на самом деле рассмотрел вмешательство. Как я могу обновить DLL, не изменяя EXE? Это то, для чего политика издателя?
Между прочим, какой-либо этот материал способен Google или способен Amazon? Что я должен искать? Я вижу много книг о C# и.NET, но ни одном о развертывании или создании или тестировании или вещах, не связанных с самим языком.
6 ответов
Я согласен с анализом Aequitarum. Просто пару дополнительных моментов:
Двигатель общий код для всех процессов, поэтому я предполагаю, что может быть общая сборка?
Это кажется разумным.
Если общий сборник находится в том же решении, что и проект, который его потребляет, как он употребляется, если он должен быть в GAC?
Magic.
Хорошо, это не волшебство. Предположим, что в вашем решении ваш процесс проекта имеет ссылку на проект двигателя . Когда вы создаете решение, вы будете создавать проект сборку , который имеет ссылку на модуль . Visual Studio затем копирует различные файлы в правильные каталоги. Когда вы выполняете сборку процесса, погрузчик времени выполнения знает, чтобы посмотреть в текущем каталоге для сборки двигателя. Если он не может найти его там, он смотрит в кэш глобальной сборки. (Это очень упрощенный вид на загрузку политики; реальная политика значительно более сложная, чем это.)
Вещи в GAC должны быть по-настоящему код ; Код, который вы разумно ожидаете большое количество разрозненных проектов для использования.
означает, что означает, что Engine.dll должен быть восстановлен на каждой сборке?
Я не уверен, что вы подразумеваете под «переименованным». Как я уже сказал, если у вас есть ссылка на проект к проекту, система сборки автоматически скопирует файлы в нужные места.
Принцип причина, причина, которую мы отделили фильтр из процесса (только один процесс использует его), так что мы можем развернуть фильтр независимо от процесса, чтобы исполняемый процесс не должен быть обновлен
Это на самом деле ценно. Сценарий One: No Filter Assember, весь код фильтра находится в Project.exe. Вы хотите обновить код фильтра; Вы обновляете Project.exe. Сценарий два: filter.dll, project.exe. Вы хотите обновить код фильтра; Вы обновляете Filtin.dll. Как сценарий две дешевле или проще, чем сценарий один? В обоих сценариях вы обновляете файл; Почему это имеет значение, то имя файла?
Однако, возможно, это действительно дешевле и легче для вашего конкретного сценария. Ключевая вещь, которую нужно понять о сборках, являются узлами, представляют собой наименьшую единицу независимо версистой и перераспределенного кода . Если у вас есть две вещи, и имеет смысл версии и отправить их независимо друг от друга, то они должны быть в разных собраниях; Если это не имеет смысла делать это, то они должны быть в той же сборке.
Я прочитал, что сборки ссылки на определенные версии других сборки, поэтому, если я обновляю только DLL, она на самом деле считается вмешательством. Как я могу обновить DLL без изменения EXE? Это то, для чего является политика издателя?
Сборка может быть дана «сильное имя». Когда вы называете свою сборку foo.dll, и вы пишете bar.exe, чтобы сказать "bar.exe зависит от foo.dll", то время выполнения будет загружаться все, что происходит с именем foo.dll; Имена файлов не являются сильными. Если злой хакер получает свою собственную версию Foo.dll на клиентском компьютере, загрузчик загрузит его. Сильное имя позволяет BAR.exe сказать «BAR.EXE версия 1.2, написанная BAR CORPORATION, зависит от версии Foo.dll 1.4, написанную корпорацией FOO», и все проверки выполняются против криптографически сильных ключей, связанных с Corp Foo Corp и Bar Corp.
Итак, да, монтаж может быть сконфигурирован только для привязки к определенной версии от конкретной компании, чтобы предотвратить вмешательство. Что вы можете сделать, чтобы обновить сборку, чтобы использовать более новую версию, создает небольшой файл XML, который сообщает Loader «Вы знаете, как я сказал, я хотел, чтобы Foo.dll v1.4? Ну, на самом деле, если 1,5 доступен, это нормально использовать Это тоже. "
Что я должен искать? Я вижу много книг о C # и .NET, но ни один о развертывании или наращивании или тестировании или вещах, не связанных с самим языком.
Развертывание часто пренебрегают в книгах, я согласен.
Я бы начал с поиска «ClickOnce», если вы заинтересованы в развертывании управляемых приложений Windows.
Проекты могут ссылаться на сборы или проекты.
Когда вы ссылаетесь на другую сборку / проект, вам разрешено использовать все публичные классы / enums / strends etc на ссылке в сборе.
Вам не нужно иметь все их в одном решении. У вас могут быть три решения, по одному для каждого процесса, и все три решения могут загружать двигатель и фильтр.
Кроме того, вы можете иметь процесс B и процессы C, ссыла на скомпилированные сборки (.dls) двигателя и фильтра и имеют аналогичный эффект.
Пока вы не устанавливаете свойство со ссылкой на сборку, требующую конкретной версии, вы можете свободно обновлять DLL без особой проблемы, предоставляя только изменения кода в DLL.
также принцип причина мы отделил фильтр из процесса (только один процесс использует его), так что Мы можем развернуть фильтр самостоятельно из процесса, так что процесс исполняемый файл не должен быть обновлен. Независимо от того, если это лучшая практика, Давайте просто катимся с этим. Это возможно?
Я фактически предпочитаю этот метод обновления. Менее накладные расходы, чтобы обновить только файлы, которые изменились, а не все каждый раз.
Что касается использования GAC, весь другой уровень сложности, которого я не буду.
Удар, подтверждающий ваши сборки, можно сделать, подписав их, что требуется для использования GAC в первую очередь, но вы все равно должны быть в порядке, пока конкретная версия не требуется.
Моя рекомендация состоит в том, чтобы прочитать книгу о .NET Framework. Это действительно поможет вам понять CLR и то, что вы делаете.
Применяемое Microsoft .NET Framework Programming была книгой, которую мне очень понравилось читать.
Вы упоминаете, что двигатель является общим кодом, поэтому вы помещаете его в отдельный проект под вашим решением. Таким образом нет ничего плохого, и не нужно добавлять эту DLL в GAC. Во время фазы вашего развития вы можете просто добавить ссылку на ваш проект двигателя, и вы сможете вызвать код из этой сборки. Когда вы хотите развернуть это приложение, вы можете либо развернуть с ним DLL Engine, либо можно добавить двигатель DLL в GAC (который является еще одним шаром воска в себе). Я склонен к развертыванию GAC, если только это не нужно. Одна из лучших функций .NET - это возможность развертывать все необходимое для запуска вашего приложения в одной папке без необходимости копировать вещи в системные папки (то есть GAC).
Если вы хотите достичь чего-то вроде динамически загрузки DLL и вызывающих методы пользователей от вашего процессора, не заботясь о конкретной версии, вы можете пойти на пару маршрутов. Самый простой маршрут должен просто установить специфичную версию , в False , когда вы добавляете ссылку. Это даст вам свободу изменения DLL позже, и до тех пор, пока вы не связываетесь с методом подписей, это не должно быть проблемой. Второй вариант представляет собой MEF (который использует отражение и будет частью структуры в .NET 4.0). Идея с MEF заключается в том, что вы можете сканировать папку «Плагинов» в папке стилей для DLL, которые реализуют определенные функциональные возможности, а затем вызывают их динамически. Это дает вам дополнительную гибкость в том, что вы можете добавить новые сборки позже без необходимости изменять ваши ссылки.
Другое, что следует отметить, что есть шаблоны установки и развертывания, встроенные в Visual Studio, что вы можете использовать для создания пакетов MSI для развертывания ваших проектов. MSDN имеет много документации, связанную с этой темой, которую вы можете проверить, здесь:
http://msdn.microsoft.com/en-us/library/ybshs20f%28vs.80%29.aspx
Мы нашли Некоторые рекомендации в MSDN. Мы начали с двух отдельных решений без общих кода, а затем абстрагировали общие возможности для общих собраний. Мы изо всех сил пытались изолировать изменения в общем коде, чтобы повлиять только на проекты, которые были готовы к нему. Мы были ужасны в открытом / закрытии .
Мы пробовали
- разветвление общего кода для каждого проекта, который использовал его, и включающий его в решение
- копирование общей сборки из общего решения, когда мы внесли изменения
- , кодирующие предварительные события, чтобы построить события Общий код для решения и скопируйте сборку
Все было настоящей болью. В итоге мы использовали одно большое решение со всеми проектами в нем. Мы отразием каждый проект, поскольку мы хотим поставить функции ближе к производству. Это отраслеет общий код также. Он много упрощает вещей, и мы получаем лучшее представление о том, какие тесты проваливаются во всех проектах, поскольку общие изменения кода.
Что касается развертывания, наши сценарии сборки настраиваются для создания кода и копирования только файлов, которые изменились, включая сборки, в нашу среду.
По умолчанию у вас есть жесткодируемый номер версии в вашем проекте (1.0.0.0). До тех пор, пока вы не изменяете его, вы можете использовать все фильтр сборки с помощью сборки процесса (он только знает, что он должен использовать версию 1.0.0.0). Это не самое лучшее решение, однако, потому что как вы различаете различные построенные самостоятельно?
Другим вариантом является использование разных версий фильтра по тому же процедуру. Вы должны добавить файл App.config в проект процесса и включите элемент BindingRedirect (см. Документы). Всякий раз, когда время выполнения ищет определенную версию фильтра, она «перенаправлена» к версии, указанной на конфиге. К сожалению, это означает, что, хотя вам не нужно обновлять сборку процесса, вам придется обновить файл конфигурации с новой версией.
Всякий раз, когда вы столкнулись с проблемами для версий, вы можете использовать fuslogvw.exe (просмотрщик Fusion log) для устранения неполадок.
весело!
Ула
Сделайте Не используйте GAC на вашей машине сборки, это деталь развертывания. Visual Studio автоматически копирует DLL в каталог сборки вашего приложения при ссылке DLL. Это гарантирует, что вы будете работать и отладки с ожидаемой версией DLL.
При развертывании у вас есть выбор. Вы можете отправить DLL вместе с приложением, которое использует его,Хранится в папке установки EXE. Ничего особенного не требуется, CLR всегда может найти DLL, и вам не нужно беспокоиться о сильных именах или версиях. Обновление исправления ошибок развернуто просто путем копирования новой DLL в папку EXE.
Если у вас есть несколько установленных приложений с зависимостью на DLL, то развертывание обновлений исправления ошибок может начать неловко. Поскольку вы должны несколько раз скопировать в DLL, один раз для каждого приложения. И вы можете попасть в неприятности, когда вы обновляете некоторые приложения, но не другие. Особенно так, когда в интерфейсе DLL есть разрывное изменение, которое требует от перекомпилирования приложения. Это DLL ALL стучит, GAC может решить это.