publishing/debugging Dynamics CRM 365 插件有更有效的方法吗？

Question

我的任务是将我们的 2008 CRM 服务器带入 Microsoft Dynamics 365 内部部署的现代时代。我有一个插件在工作，java 脚本是我的第一个任务，debugging/remote 调试也在工作。我还可以对 DLL 进行更改并且所做的更改有效。但是，我真的很关心将 DLL 发布到服务器的过程需要多长时间，并且想知道是否遗漏了什么。看了很多视频，在谷歌上搜索了很多，但似乎每个人都知道如何让它工作，仅此而已。

我注意到在注册过程中有一个选项 select 'Disk' 用于 DLL 的位置，但是当我 select 它时它就崩溃了？所以我不得不 select 'Database'

初始设置：

构建添加注释的插件'A'
将 DLL 从 bin\Debug 复制到服务器 bin\assembly 文件夹。
将插件注册为 Sandbox/Database
测试成功。

目前我的开发流程是：

稍微修改插件代码以显示 'B' 而不是 'A'
重建 DLL。
将 DLL 从 bin\Debug 复制到服务器 bin\assembly 文件夹。
测试，它仍然显示 'A'

我唯一能做到这一点的方法，似乎必须有更简单的方法：

重建 DLL 的
将 DLL 从 bin\Debug 复制到服务器 bin\assembly 文件夹。
开启注册
再次定位 DLL
勾选插件selection boxes
点击更新select编辑插件
测试并显示 'B'

如果您需要快速更改重建测试，这似乎是一个真正的 PIA，我怀疑我需要这样做。

有没有更简单的方法？

Answer 1

插件发布和调试肯定是一个挑战。

就发布而言，我使用商业第 3 方 Visual Studio 扩展程序 XrmToolkit (no affiliation), which is not to be confused with the wildly popular community-supported XrmToolbox 应用程序。

XrmToolkit 使您能够直接从 Visual Studio 配置、构建和发布插件。这大大简化了发布更新的过程。

Microsoft 曾经有一个 Developer Extensions 工具，Jason Lattimer 也有一个，但我不确定它们中的任何一个是否还在积极开发中。

我通常采用的另一种技术是将插件代码放入 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);
}

请参阅 this answer。

Answer 2

虽然我在上面使用的方法是可行的，但它非常痛苦并且容易出错。我发现重新启动 IIS 服务器也可以，但导航到并重新启动它确实不是一个可行的选择。

我发现曾经有一个开发人员工具，正如 Aron 提到的那样，名为 'Microsoft Dynamics 365 Developer Toolkit'，您可以从 MS 下载 here

对于 Visual Studio 2017，您将需要编辑 vsix：

使用 7Zip 解压或重命名为 zip 并解压到文件夹。
在文件夹中您会找到 extension.vsixmanifest
编辑文件并替换行

InstallationTarget Version="[11.0,14.0]"

与：

InstallationTarget Version="[11.0,15.0]"

这告诉清单允许在 2017 年安装
重新压缩文件夹的内容（不是文件夹）
将压缩文件重命名为 .vsix
安装 vsix
忽略警告并完成安装。

您现在应该在 VS2017 的新项目部分中有一个新的 Dynamics CRM 部分。

您需要进入 'Tools > Options > Dynamics 365 Development Toolkit > Tool Paths' 并设置您的 CRMSDK bin 和 Tools/PluginRegistrationTool 文件夹的路径。

创建新项目：

新项目
Select "New Visual Studio Solution Template for Dynamics 365"

要添加一个新的帐户实体，例如：

VS2017 > CRM 资源管理器
右键单击帐户 > 创建插件

现在，除非我在您右键单击 'Package' 并选择“部署”时忘记了什么，否则它将部署到您的 CRM 服务器 ;)

此致，戴夫

tip 1：我们365服务器指向的CRM SDK实际上指向的是微软的2015 SDK。由于该工具包需要 8.0 或更高版本，这让我有些吃惊；）

Answer 3

这是我多年前使用的开发工作流程，涉及手动部署和测试插件。现在我使用更现代和更有效的方式来开发和测试插件 TDD (Test Driven Development).

传统的手动工作流程涉及：

1) 修改插件
2) 通过插件注册或其他 VS 扩展部署插件
3) 在目标环境中手动测试插件/附加远程调试器/分析器
4) 重复

这是一个非常耗时的工作流程。

有了更加自动化的开发工作流程，它变成了：

1) 修改插件
2) 在本地调试/测试
3) 重复
4) 推送您的更改，让 CI 触发构建并发布您的插件

或者如果严格遵循 TDD：

1) 根据要求添加/更新任何必要的单元测试，这将导致您的插件失败，因为该插件还没有验证这些要求的实现逻辑
2) 更新您的插件代码，使单元测试通过
3) 自信地重构您的代码（确保单元测试仍然通过）
4) 推送您的更改
5) 让 CI 构建和发布自动化触发

主要区别在于，使用 TDD 方法，您的开发和测试反馈循环要快得多，并且您（通常）最后只需要一个部署步骤，这也可以自动化。

您还可以利用现有的开源框架，这些框架允许为您模拟 Microsoft SDK 中的大部分接口，例如 FakeXrmEasy（我是作者）。

希望对您有所帮助

publishing/debugging Dynamics CRM 365 插件有更有效的方法吗？

Is there are more efficient way of publishing/debugging Dynamics CRM 365 Plugins?

.net

plugins

dynamics-crm