从 PowerShell 管理单元引用外部程序集
我正在开发一个自定义 PowerShell 管理单元，它引用解决方案中的另一个项目。
当我尝试调试管理单元（按照[这些说明][1]）时，程序集无法加载，并且我的 cmdlet 失败，并显示消息“无法加载文件或程序集...”
您如何指导 PowerShell 如何操作定位程序集，或者如何指定管理单元所需程序集的位置？
我宁愿避免在 GAC 中注册程序集，至少在开发期间是这样。
I'm developing a custom PowerShell snap-in, which references another project in the solution.
When I try to debug the snap-in (following [these instructions][1]), the assembly fails to load and my cmdlet fails with the message "Could not load file or Assembly..."
How do you instruct PowerShell on how to locate assemblies, or how do you specify where are located the assemblies needed by the snap-in?
I'd prefer to avoid registering the assemblies in the GAC, at least during development.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不确定确切的行为，但我会尝试使用 Fuslogvw 来准确查看运行时在哪里寻找有问题的程序集。这将为您提供有关如何将它们复制到构建时的正确位置的线索。 Scott Hanselman 的这篇文章是非常有用，这是官方的文档。
如果您找到解决方案，请添加答案，因为这一定是常见情况。
Not sure of the exact behaviour, but I would try and make use of
fuslogvwto see exactly where the runtime is looking for the problematic assemblies. That would give you a clue as to how to get them to be copied into the correct place on build. This post by Scott Hanselman is quite useful, and this is the official documentation.If you find the solution, please add an answer, as this must be a common scenario.
解决方案（按照我的问题的评论之一的建议将其发布到此处）
我的问题相当具体，因为我正在 64 位服务器计算机上进行开发，但我发布了解决方案，以防万一它也可以帮助别人。
按照建议使用
fuslogvw，我看到正在使用C:\Windows\Microsoft.NET\Framework64machine.config文件搜索依赖程序集code> 然后绑定失败；使用“启动而不调试”启动项目，而是获取C:\Windows\Microsoft.NET\Framework下的machine.config文件（注意缺少的>64位于末尾）。我认为问题可能是由于图像格式造成的，事实上依赖程序集是使用 x86 作为 CPU 目标进行编译的；我将其更改为“任何 CPU”，现在程序集已正确加载。
SOLUTION (Posting it here as suggested by one of the comments to my question)
My problem was rather specific, as I'm developing on a 64 bits server machine, but I'm posting the solution in case it could help someone else as well.
Using
fuslogvwas suggested, I saw that the dependent assembly was being searched using themachine.configfile underC:\Windows\Microsoft.NET\Framework64and then the binding failed; launching the project with "start without debugging", instead, themachine.configfile underC:\Windows\Microsoft.NET\Frameworkwas taken (notice the missing64at the end).I thought that the problem could be due to the image format, and infact the dependent assembly was being compiled with x86 as CPU target; I changed it to "Any CPU" and now the assembly is loaded correctly.