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