Развернуть сборку как часть .Net Framework - PullRequest
0 голосов
/ 27 июня 2018

У меня есть сборка (MYASM.dll) для .NETFramework 4.0 (со строгим именем)

Я хочу развернуть эту сборку таким образом, чтобы она была частью .NETFramework (или так думает вся система) на целевой машине.

Под этим я подразумеваю:

  1. .NET runtime видит, как видит System.dll (нет необходимости развертывать локально или указывать путь ссылки)
  2. MSBuild видит это, когда я делаю <Reference Include="MYASM" /> без подсказки
  3. Пользователь может сделать Add reference в Visual Studio, и это вводит <Reference Include="MYASM" /> без строгого / полного имени

Я решил 1. (и, видимо, 2.), добавив его в GAC. Но этого явно недостаточно.

Я частично решил 3. поместив мою сборку в специальную папку ([INSTALLFOLDER]\lib) и установив параметр RegistryKey HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0\AssemblyFoldersEx\MyAssemblies

Тогда я могу сделать Добавить ссылку, но тогда я получу:
<Reference Include="MYASM, Version=1.1, Culture=neutral, ..." /> в моем csproj вместо просто <Reference Include="MYASM" />, как я хотел бы.

При втором подходе, если я вручную отредактирую csproj, все в порядке, но я не могу попросить своих пользователей сделать это.

Что мне здесь делать?

[ПРАВИТЬ], очевидно, не очевидно, что у меня есть свой собственный MSI. Но да, у меня есть. Я не управляю машинами пользователей волшебной палочкой

Ответы [ 3 ]

0 голосов
/ 11 июля 2018

Нет, вы взяли это настолько далеко, насколько это возможно. На самом деле не совсем очевидно, как VS решает поместить частичное имя сборки в файл проекта. Это не публичный код и не может быть подделан. Уверен, он не использует белый список и не может обращать внимание на расположение эталонной сборки.

Наиболее вероятная деталь - PublicKeyToken сборки. Сборки каркаса всегда должны иметь одинаковое значение для них, b77a5c561934e089. Его значение даже прописано в спецификации CLI (Ecma-335). Следующим, скорее всего, на значительном расстоянии является сертификат подписи, идентифицирующий сборку как принадлежащую Microsoft. Однако оба варианта представляют собой одну и ту же проблему: вы не можете получить закрытый ключ, необходимый для строгого имени или подписи сборки. Они заперты в хранилище в Редмонде, доступ к ним имеют только проверенные инженеры-строители.

Есть еще одна неприятная маленькая деталь, которую вы упускаете из виду, вы недостаточно напуганы DLL Ада. Неожиданный факт заключается в том, что если вы когда-либо выставите сборку в GAC на другой машине, которая не находится под вашим контролем, вы никогда не сможете изменить ее снова. Вы больше не можете изменять открытый интерфейс сборки. Невозможно добавить новый общедоступный метод или тип, нельзя изменить аргументы и вернуть тип метода, нельзя добавить член enum и т. Д. Еще более резким моментом, который беспокоит Microsoft, является то, что вы не можете реально изменить частные и внутренние члены либо. У программистов есть ловкость в использовании Reflection для потрясающего исправления ошибок. Но, по крайней мере, вы можете сказать им: «Не делай этого!».

Для внесения такой модификации требуется увеличение [AssemblyVersion]. Теперь вы получаете другой тип DLL Hell, возможно, ваш компьютер не обновил ваш установщик. Или хуже, решение использует проекты, которые имеют разные ссылки. Microsoft пришлось решить эту проблему для сборок фреймворка, они сделали это путем изменения CLR. Автоматическая пересылка старых версий на новые. Основная причина, по которой использование сборки, созданной для .NET 2.0, может быть использована в проекте .NET 4.x. Вы не можете получить такую ​​услугу для своей собственной DLL.

«Не делай этого» - единственный хороший совет, попав в DLL Проблема с адом - это, однако, потрясающий опыт обучения, который я могу рекомендовать любому. Чтобы испытать страх, нужно испытать ад.

Лучший совет - опубликовать пакет Nuget. Они делают прямо противоположное, никогда не разворачиваются в GAC, и номера версий меняются очень быстро. Но всегда доступно, когда это нужно программисту.

0 голосов
/ 11 июля 2018

Есть несколько способов ...

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

2) Создайте пакет NuGet, если вы нацелены на разработчиков. Если в вашей организации размещен собственный сервер NuGet, ограничивающий распространение. Добавьте источник пакета в Visual studio, откройте страницу параметров, введите NuGet в поле поиска и укажите путь URL / UNC.

enter image description here

3) использовать развертывание OneClick, это позволяет приложению загружать обновленные библиотеки DLL и устанавливать их на компьютер. Для этого требуется сертификат Code Sign, но вы, вероятно, все равно подписываете свой код (лучше для инструментов Антивируса, если вы это делаете)

Теперь связывание вашего MyAsam.dll будет производиться с помощью определения связывания приложения или контейнера IoC. В основном, если он находит dll, и ни одна версия не определена, он возьмет первую найденную версию. Я думаю, что порядок: 1 AppFolder, 2 GAC, 3 Path, не уверен. Это «возьми то, что ты найдешь» обычно называют «DLL-Hell», лучше всего в этом работают решения NuGet и OneClick, так как вы всегда получите обновленную dll, которая работает для приложения. Поместить DLL в GAC будет проблематично, если у вас более 1 приложения, использующего вашу dll, и оба нуждаются в «правильной» версии, где «правильная версия» отличается между ними ....

0 голосов
/ 11 июля 2018

Если у вас есть исходный код для MYASM.dll, я бы предпочел добавить ссылку на проект в ваше приложение-потребитель. При этом Visual Studio должна создать GUID для всего ссылочного проекта.

...