我正在测试一个使用 Add-Type 添加一些自定义 C# 代码的工作流运行手册。
突然之间，我开始在后续测试作业中出现“类型已存在”错误，好像没有创建新的 PSSession。
换句话说，看起来新作业共享相同的执行上下文。如果我尝试为每个 PS 实例运行两次相同的命令，我只会在本地得到这个。
有问题的类型是带有一些扩展方法的静态类。由于它也恰好是源代码块中声明的第一个类型，我不怀疑其他非静态类型也会引发错误。
我已经执行了好几次了，所以我完全希望“最终”这将停止发生，但我似乎无法强迫它，我不知道我能做些什么让它陷入这种情况， 任何一个。
看到像这样跨作业共享执行上下文的证据 - 甚至（尤其是？）如果只是暂时的 - 让我想知道我们过去在进行和部署更改以及执行后续测试时看到的部分或全部一般执行不一致 -之后都与此有关。
我很想认为这只是测试作业和“真实”作业之间差异的一部分，但这引发了关于测试作业本身 WRT 模仿已发布作业的有效性的问题。
是否所有 Azure 自动化作业都应该隔离执行？这可以由开发人员控制/利用吗？
每个自动化帐户都有自己的隔离沙箱，用于运行其作业。这些沙箱分布在许多工作机器中。对于测试作业，由于反复 [进行代码更改，重新测试] 非常常见，因此尝试改进作业开始时间，如果沙箱尚未清理，自动化将重用与本运行手册的先前测试作业相同的沙箱，因此不必为每个唯一的测试作业启动沙箱（沙箱创建是作业开始时间比预期长的原因之一）。由于此行为，如果您在短时间内执行同一 Runbook 的测试作业，您将获得上述行为。
但是，即使对于生产作业，同一自动化帐户（跨运行手册）的作业也可以共享相同的沙箱。我们在我们的工作机器上随机分配作业，因此它可能的作业 A 排队等待执行并放置在工人 W 上，然后 5 分钟后，作业 B 排队等待执行并且也放置在工人 W 上。如果作业 A 和作业 B 属于同一个自动化帐户，并且在模块/模块版本方面具有相同的“需求”，则它们将被放置在同一个沙盒中，如果作业 A 的沙箱还在。“模块/模块版本要求”并不表示 Runbook 使用的模块，
在解决您的特定问题方面，您可以用 try、catch 语句包围 Add-Type，或者使用Add-Type -IgnoreWarnings