Есть ли более эффективный способ публикации / отладки подключаемых модулей Dynamics CRM 365?

Question

Мне было поручено привести наш сервер CRM 2008 года в современную эпоху Microsoft Dynamics 365 локально. У меня есть работающий плагин и скрипт java, который является моей первой задачей, и отладка / удаленная отладка тоже работает. Я также могу внести изменения в DLL и изменения работают. Тем не менее, я действительно обеспокоен тем, как долго выполняется процесс публикации sh библиотеки DLL на сервере, и подумал, что я что-то упустил. Смотрел немало видео, много гуглил, но, кажется, все рассказывают, как это работает, и все.

Я отмечаю, что во время регистрации есть возможность выбрать «Диск» для расположения библиотеки DLL, но она просто падает, когда я выбираю ее? поэтому мне нужно выбрать «База данных»

Начальная настройка:

• Создать плагин, который добавляет примечание «A»
• Скопировать библиотеки DLL из bin \ Debug на папку bin сервера>. 1010 *
• зарегистрируйте плагин в качестве тестовой среды / базы данных
• test и он работает.

В настоящее время мой рабочий процесс разработки:

• немного измените код плагина, чтобы вместо 'A' отображалось 'B'
• Перестройте библиотеки DLL.
• Скопируйте библиотеки DLL из bin \ Debug в папку bin \ Assembly сервера. * Тест 1024 *
• , и он все еще показывает 'A'

ЕДИНСТВЕННЫЙ способ, которым я смог заставить это работать, и кажется, что должен быть более простой способ:

• Перестройте библиотеки DLL
• Скопируйте библиотеки DLL из bin \ Debug в папку bin \ Assembly сервера.
• Откройте регистрацию
• , найдите библиотеку DLL снова
• Установите флажки для выбора плагинов
• нажмите обновить выбранные плагины
• test, и он покажет «B»

Это кажется настоящей PIA i f вам нужно быстро изменить тест восстановления, который, как я подозреваю, мне понадобится.

Есть ли более простой способ?

Answer 1

Публикация и отладка плагинов могут быть проблемой наверняка.

Что касается публикации, я использую коммерческое стороннее расширение Visual Studio XrmToolkit (без принадлежности), которое не следует путать с популярным XrmToolbox, поддерживаемым сообществом. app.

XrmToolkit позволяет настраивать, создавать и публиковать sh плагин непосредственно из Visual Studio. Это значительно упрощает процесс публикации обновлений.

У Microsoft раньше был инструмент Developer Extensions, и у Джейсона Латтимера тоже был такой, но я не уверен, что какой-либо из них уже находится в активной разработке.

Другая техника, которую я обычно использую, - это вставка кода плагина в общий проект Visual Studio, на который я ссылаюсь как из проекта плагина, так и из консольного приложения. Я использую Консольное приложение для разработки и отладки перед публикацией плагина. После запуска плагина я продолжу использовать консольное приложение для устранения неполадок или создания улучшений.

Например:

///Shared Project
public class MyPluginApp
{
    private IOrganizationService svc;
    public MyPluginApp(IOrganizationService svc)
    {
        this.svc = svc;
    }

    public void Run(Account target)
    {
        //do stuff with the Target
    }
}

////Plugin
public void Execute()
{
    var app = new MyPluginApp(context.Service);
    app.Run(context.Target);
}

///Console App
public static void Main()
{
    var svc = new CrmServiceClient(connectionString);
    var target = getLastTouchedAccount(svc);
    var app = new MyPluginApp(svc); 
    app.Run(target);
}

См. Также этот ответ .

Answer 2

Это рабочий процесс разработчика, который я использовал много лет go, включая ручное развертывание и тестирование плагинов. В настоящее время я использую гораздо более современный и эффективный способ разработки и тестирования плагинов с использованием TDD (Test Driven Development) .

Традиционный ручной процесс включает в себя:

• 1) Внести изменения в плагин
• 2) Развернуть плагин с помощью регистрации плагинов или других расширений VS
• 3) Тестировать плагин вручную в целевой среде / подключить удаленный отладчик / профилировщик
• 4) Повторите

Это очень трудоемкий рабочий процесс.

С более автоматизированным рабочим процессом разработчика вместо этого он становится:

• 1) Внесите изменения в Плагин
• 2) Локальная отладка / тестирование
• 3) Повторите
• 4) Pu sh ваши изменения, и позвольте триггеру CI создать и выпустить ваш плагин

Или если строго следовать TDD:

• 1) Добавить / обновить все необходимые юнит-тесты в соответствии с требованиями, это приведет к сбою ваших плагинов, так как этот плагин не ' у него есть логика реализации c, которая проверяет Требований к себе пока нет
• 2) Обновите код своего плагина, чтобы модульные тесты проходили
• 3) С уверенностью проведите рефакторинг вашего кода (убедившись, что юнит-тесты все еще проходят)
• 4) Pu sh ваши изменения
• 5) Пусть CI скомпилирует и выпустит триггер автоматизации

Основное отличие состоит в том, что при подходе TDD ваша обратная связь с разработчиком и тестом l oop гораздо быстрее, и вам (обычно) требуется только один шаг развертывания в конце, который также может быть автоматизирован.

Вы также можете использовать существующие платформы с открытым исходным кодом, которые позволяют создавать большинство интерфейсов. в Microsoft SDK для вас, как FakeXrmEasy (который я автор).

Надеюсь, это поможет

Answer 3

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

Я обнаружил, что раньше был инструмент разработчика, о котором упоминал Арон, под названием «Microsoft Dynamics 365 Developer Toolkit». которую вы можете скачать с MS здесь

Для Visual Studio 2017 вам необходимо отредактировать vsix:

• Извлечь с помощью 7Zip или переименовать в zip и извлечь в папка.
• в папке вы найдете extension.vsixmanifest
• , отредактируйте файл и замените строки

InstallationTarget Version="[11.0,14.0]"

с:

InstallationTarget Version="[11.0,15.0]"

• это указывает манифесту разрешить установку в 2017
• и распаковывает содержимое папки (НЕ папки )
• переименуйте заархивированный файл как .vsix
• установите vsix
• игнорируйте предупреждение и завершите установку sh.

Вы должны теперь добавьте новый раздел Dynamics CRM в раздел нового проекта VS2017.

Вам потребуется go в «Инструменты> Параметры> Dynamics 365 Development Toolkit> Пути к инструментам» и указать путь к своей корзине CRMSDK и папке Tools / PluginRegistrationTool.

Чтобы создать новый проект:

• Новый проект
• Выберите «Новый шаблон решения Visual Studio для Dynamics 365»

Чтобы добавить новую учетную запись, например:

• VS2017> CRM Explorer
• Щелкните правой кнопкой мыши Учетная запись> Создать плагин

Теперь, если я что-то не забыл, когда вы щелкнете правой кнопкой мыши по «Пакету» и выберите «Развернуть» он будет развернут на вашем сервере CRM;)

С уважением, Дейв C

совет 1: CRM SDK, на который указывает наш сервер 365, фактически указывает на SDK 2015 от Microsoft. Вызвала некоторую тревогу от моего имени, так как инструментарий требует 8.0 и выше;)