ADF V2是否仍支持DotNetActivity？升级v1管道后需如何处理？

很明确地说：Azure Data Factory (ADF) v2 已经完全移除了对 v1 中 DotNetActivity 的支持，官方文档的活动列表里确实找不到这个组件，你需要把原有基于 IDotNetActivity 接口的逻辑迁移到 CustomActivity 上。下面是具体的迁移步骤和注意点：

• 重构代码为控制台应用：
  原来继承 IDotNetActivity 的类是通过 Execute 方法接收ADF上下文和输入的，现在要把核心逻辑迁移到一个.NET控制台应用的 Main 方法中。如果有多个DotNetActivity，可以考虑把公共逻辑提取到类库，让各个控制台应用引用，减少重复代码。

• 处理输入输出的传递：
  原来的 DotNetActivity 可以直接通过方法参数获取ADF的输入数据集和属性，现在CustomActivity需要通过以下方式传递信息：

  • 用 extendedProperties 配置键值对参数，控制台程序可以通过读取环境变量（ADF会把这些属性注入到运行环境中）来获取。
  • 如果是需要处理文件，把输入数据集指向Azure存储的文件，控制台程序直接读取该路径下的文件即可；输出同理，把生成的文件写入指定的输出数据集路径。

• 打包与部署：
  把控制台应用编译为可执行文件，连同所有依赖的DLL（包括第三方库）一起打包成ZIP文件，上传到Azure Blob存储的容器中。然后在ADF v2的CustomActivity里配置：

  • Linked Service：选择指向该Blob存储的Azure存储链接服务。
  • Package Linked Service：同样指向该Blob存储链接服务，指定ZIP包的路径。
  • Command：填写运行命令，比如 YourAppName.exe [参数1] [参数2]。

• 测试要点：
  迁移完成后，重点测试这几个方面：

  • 参数传递是否准确，尤其是原来依赖ADF上下文的属性是否正确获取。
  • 依赖项是否齐全，避免出现运行时找不到DLL的错误。
  • 错误处理逻辑是否正常工作，比如异常是否能被ADF捕获并标记为失败。
  • 性能是否和原来的DotNetActivity一致，必要时调整CustomActivity的虚拟机规格。

如果你的DotNetActivity数量较多，建议先迁移一个典型的案例，验证流程没问题后再批量处理，这样能减少返工的风险。

内容的提问来源于stack exchange，提问作者Yoshinobu Furuya