如何管理 x86 和 x64 版本的 PowerShell 管理单元的开发
我目前正在编写一个 PowerShell 管理单元，它对专门针对 x64 或 x86 的混合模式程序集（包含本机代码的程序集）有特定的依赖性。我有两个版本的依赖程序集，但我想知道如何最好地管理此管理单元的构建和部署，具体来说：
- 是否有必要拥有两个版本的管理单元（一个 x86 和一个 x64），并使用两个不同的版本installutil 来安装它，每个架构一次？
- 假设#1为真，是否建议在不同的“Program Files”和“Program Files (x86)”目录中安装两个不同版本的管理单元？
- 为了构建两种不同的架构，构建两个共享除单个引用之外的所有内容的项目的理想（最不麻烦）方法是什么？
- 如果管理单元编译为“AnyCpu”，并且依赖的 dll 都加载到 GAC 中，运行时是否会根据当前运行的 PowerShell 主机的体系结构从 GAC 加载正确的程序集？
- 是否有一种巧妙的方法可以在运行时动态选择要加载的依赖 dll（如果由于各种原因无法将其安装在 GAC 中），而不会遇到程序集加载上下文的麻烦？
I am currently writing a PowerShell snapin that has specific dependencies on mixed-mode assemblies (assemblies containing native code) that specifically target x64 or x86. I have both versions of the dependent assembly, but I am wondering how best to manage the build and deployment of this snapin, specifically:
- Is it necessary to have two versions of the snapin, one x86 and one x64, and use the two different versions of installutil to install it, once for each architecture?
- Assuming #1 is true, is it recommended to install the two different versions of the snapin in the different "Program Files" and "Program Files (x86)" directories?
- What is the ideal (least hassle) way to structure a pair of projects that share everything but a single reference, in order to build for the two different architectures?
- If the snapin is compiled as "AnyCpu", and the dependent dlls are both loaded into the GAC, will the runtime load the correct assembly from the GAC based on the architecture of the currently running PowerShell host?
- Is there a slick way to dynamically, at run-time, choose which dependent dll to load (if it cannot, for various reasons, be installed in the GAC) without running into headaches with assembly load contexts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
马克，我们在使用 32 位和 64 位版本 7zip.dll 的 PowerShell 社区扩展时遇到了这种情况。您可以在管理单元启动初期（或在需要调用本机 DLL 之前）通过 PInvoking 调用 LoadLibrary 轻松解决此问题。然后，您可以测试您是 32 位还是 64 位进程 (IntPtr.Size)，然后使用 LoadLibrary PInvoke 手动加载正确的 DLL。之后，DllImport("YourNative.dll") 将注意到该 dll 已加载并使用该 DLL。
看一下这两个PSCX源代码文件：
http://pscx.codeplex.com/SourceControl/changeset/查看/74794?ProjectName=Pscx#1358100
http://pscx.codeplex.com/SourceControl/changeset/查看/74794?ProjectName=Pscx#1358102
Mark, we have this very situation with the PowerShell Community Extensions with 32-bit and 64-bit versions of 7zip.dll. You can pretty easily work around this by PInvoking to LoadLibrary early in your snapin startup (or before you need to call out to the native DLL). You can then test if you're a 32-bit or 64-bit process (IntPtr.Size) and then load manually the correct DLL using the LoadLibrary PInvoke. After that the, DllImport("YourNative.dll") will notice that the dll is already loaded and use that DLL.
Take a look at these two PSCX source code files:
http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358100
http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358102
我最终创建了一个模块（谢谢，理查德！），但这并没有解决与处理器架构相关的问题。为了解决这个问题，我将两个版本的依赖 dll 放在模块目录中，并在每个 cmdlet 的构造函数中放置一些初始化代码（仅运行一次）来加载相应版本的依赖 dll。
谢谢大家指点。
I ended up creating a module (thanks, Richard!), but that didn't solve the problems related to processor architecture. In order to solve that, I put both versions of the dependent dll in the module directory, and in each cmdlet's constructor I put some initialization code (that only runs once) to load the appropriate version of the dependent dll.
Thanks, all, for the pointers.