Общий проект - альтернатива ILMerge в разработке плагинов Dynamics CRM

Слияние сборок для индивидуальной разработки в Dynamics пока что головная боль !!

Когда дело доходит до слияния сторонних dll, таких как newtonsoft.json, со сборкой плагинов в CRM, мы всегда опирались на ILMerge - волшебный инструмент, который объединяет сборки и решает проблемы с настраиваемыми плагинами и рабочими процессами.

Давайте разберемся, что это за инструмент и как он решил эту задачу !!

Что такое ILMerge?

ILMerge - это служебная программа от Microsoft, позволяющая объединить набор сборок в один файл. Это можно использовать для слияния исполняемого файла с поддерживающими его динамически подключаемыми библиотеками (DLL), чтобы вы могли распространять исполняемую программу в виде одного файла. Его также можно использовать для упрощения больших библиотек, которые в противном случае включали бы несколько DLL, на каждую из которых нужно было ссылаться из проекта, который их использует.

Инструмент ILMerge можно использовать как служебную программу командной строки или на него можно ссылаться в проекте и использовать программно. В этой статье мы рассмотрим базовую функциональность, предоставляемую вариантом командной строки.

Более подробную информацию о ILMerge с разработкой подключаемых модулей CRM можно найти по ссылкам ниже

ILMerge больше не поддерживается для разработки Dynamics?

ILMerge сейчас не поддерживается для разработки Dynamics CRM, как указано в сообщении в блоге ниже.

Https://cloudblogs.microsoft.com/dynamics365/no-audience/2010/11/09/how-to-reference-assemblies-from-plug-ins/?source=crm

«31.08.15Этот пост был отредактирован, чтобы отразить, что Dynamics CRM не поддерживает ILMerge. Он не заблокирован, но не поддерживается в качестве опции для ссылки на пользовательские сборки ».

Может ли ILRepack заменить ILMerge?

ILRepack - это инструмент, позволяющий объединить несколько сборок в одну сборку. Это может быть полезно при развертывании приложения, которое имеет несколько зависимостей. В этом случае вы можете объединить все dll и exe в один файл exe, чтобы его было проще развернуть. Это также полезно, если вы создаете пакет NuGet. В этом случае это позволяет удалить зависимости, которые вы не хотите раскрывать своим потребителям. Например, если ваша библиотека зависит от Newtonsoft.Json в частном методе, вы можете объединить эту библиотеку в свою dll, чтобы избежать раскрытия пакета NuGet как зависимости от вашего пакета NuGet. Это может предотвратить некоторые проблемы, если несколько пакетов NuGet зависят от разных версий Newtonsoft.Json.

Более подробную информацию о ILRepack и о том, как его настроить, можно найти по ссылкам ниже

А как настроить ILRepack для проектов Dynamics можно найти по ссылке ниже.

Давайте перейдем к нашей теме о том, как использовать встроенные функции Visual Studio для решения нашей проблемы!

Общие проекты Скрытые сокровища и Спаситель

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

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

Более подробную информацию об общем проекте можно найти ниже

Https://docs.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/shared-projects?tabs=windows

Иллюстрация использования общих проектов при разработке плагинов CRM

Возьмем простое требование

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

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

Логика:

Шаг 1. Контекст GetAccount

Шаг 2. Если он содержит номер счета

Шаг 3. Получите номер счета из PostImage или Entity.

Шаг 4: Обновите

[Получить соответствующее рабочее задание

Где WO.ServiceAccountid = Account.AccountID

И WO.statecode = Active]

WO.AccountNumber = Step3.accountnumber

Давайте посмотрим, как добиться этого с помощью кода и зачем нужен общий проект здесь?

Мы можем просто создать один проект для плагинов для вышеуказанной логики и можем поместить в него весь наш код, построить и зарегистрировать его в CRM, но что произойдет, если я захочу повторно использовать этот код для настраиваемого рабочего процесса или для функций Azure, мне нужно повторить тот же код, который может повлиять на мою ремонтопригодность.

И это станет так сложно для модульного тестирования.

Чтобы решить эту проблему, мы собираемся создать следующие компоненты, которые получат некоторую часть шаблона проектирования фабрики.

Бизнес-логика

Этот компонент будет иметь только код бизнес-логики / процесса, который будет напрямую взаимодействовать с плагином.

DataAccessLayer

Этот Компонент будет иметь всю необходимую логику для запроса и управления всеми связанными данными, которые требуются для бизнес-логики.

Плагин Entry

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

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

Шаг 1. Создайте пустое и пустое решение в VS 2019

Шаг 2. Добавьте новый общий проект в решение, как показано на скриншоте ниже.

Шаг 3. Добавьте новый проект библиотеки классов для плагина

Шаг 4. Установите пакеты nuget для сборок ядра для сборок SDK с помощью диспетчера пакетов.

Шаг 5. Укажите ссылку на общий проект в проекте плагина, как показано ниже.

Шаг 6. Создайте необходимые модели данных и уровень доступа к данным для WorkOrder в соответствии с приведенными ниже фрагментами кода.

Шаг 7. Вызовите эту бизнес-логику из проекта плагина, как указано в исходном коде.

Шаг 8. Создайте проект плагина и подпишите сборку.

Шаг 9: Используйте дизассемблер, такой как dotpeek, чтобы увидеть внутреннее устройство dll плагина, которое будет включать проект бизнес-логики, а также как на изображении ниже.