CRM с использованием ILMerge для объединения библиотеки фреймворка с проектами плагинов

У меня две сборки:

  1. Сборка основного плагина - плагин, используемый в моем проекте
  2. Сборка фреймворка - я хочу объединить эту сборку с основным плагином, чтобы я мог повторно использовать некоторые общие методы, часто используемые в разных проектах.

Я установил ILMerge в сборку основного плагина и сослался на встроенные библиотеки DLL фреймворка, одновременно задав порядок сборки проекта в решении.

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

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

Все упомянутые выше проекты существуют в одном решении.

Я новичок в ILMerge, так что могу делать что-то не так, это очевидно. Я просто компилирую, используя встроенный компилятор Visual Studio.

Может ли кто-нибудь подсказать, что может пойти не так?

2 ответа

Во-первых, я советую использовать ILRepack, поскольку ILMerge больше не поддерживается активно. ILRepack основан на ILMerge и имеет открытый исходный код. Добавить пакет NuGet ILRepack.Lib.MSBuild.Task к вашему проекту.

Затем добавьте этот файл в свой проект и назовите его ILRepack.targets:

      <?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="ILRepacker" AfterTargets="Build">
    <ItemGroup>
      <InputAssemblies Include="$(OutputPath)$(TargetName)$(TargetExt)" />
      <InputAssemblies Include="$(OutputPath)YourFramework.dll" />
    </ItemGroup>
    <ILRepack
        Parallel="true"
        Internalize="false"
        InternalizeExclude="@(DoNotInternalizeAssemblies)"
        InputAssemblies="@(InputAssemblies)"
        LibraryPath="$(OutputPath)"
        Wildcards="false"
        TargetKind="SameAsPrimaryAssembly"
        DebugInfo="false"
        KeyFile="$(SolutionDir)Eneco.snk"
        OutputFile="$(OutputPath)Merged\$(AssemblyName).dll"
        LogFile="$(OutputPath)Merged\ILRepack.log"
    />
  </Target>
</Project>

Обратите внимание, что в соответствии с этой конфигурацией ваша объединенная dll создается в отдельной папке с именем «Merged». Это библиотека, которую вы регистрируете в Dynamics 365. Модульные тесты должны просто использовать обычные выходные данные сборки проекта подключаемого модуля.

Если у вас есть весь код для сборки фреймворка, одним из вариантов будет использование общего проекта Visual Studio .

Помещение кода фреймворка в общий проект позволит вам скомпилировать ваш плагин и код фреймворка в единую сборку без каких-либо дополнительных инструментов.

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

Другой вариант - добавить исходные файлы фреймворка в качестве ссылок на проект плагина.

Другие вопросы по тегам