Powershell - 在应用程序配置文件中未找到程序集绑定重定向 [英] Powershell - Assembly binding redirect NOT found in application configuration file
问题描述
我有一个 Powershell CmdLet，它可以在 32 位模式下运行而在 64 位模式下失败.问题是原因是什么以及如何解决.
I have got a Powershell CmdLet that works when running in 32-bit mode and fails in 64-bit mode. Question is what the cause is and how it can be fixed.
引用OutlookHelper.Common.dll"的Powershell CmdLet.最新版本是 2.0.0.0CmdLet 还使用日志记录并引用Logging.dll".
Logging.dll 还引用了OutlookHelper.Common.dll"，仅针对版本 1.0.0.0 编译.
Powershell CmdLet that references 'OutlookHelper.Common.dll'. Newest version is 2.0.0.0
The CmdLet also uses logging and references 'Logging.dll'.
Logging.dll also references 'OutlookHelper.Common.dll', only was compiled against version 1.0.0.0.
在 Powershell 的应用程序配置文件中使用程序集绑定重定向:
Using an assembly binding redirect in the application configuration file of Powershell:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="OutlookHelper.Common" publicKeyToken="5e4553dc0df45306"/>
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Powershell 32 位工作正常
在 64 位机器上运行时，使用Windows Powershell (x86)"即可.程序集管理器找到一个程序集绑定重定向:
Powershell 32-bits works just fine
When running on a 64-bits machine, using 'Windows Powershell (x86)' it works. The assembly manager finds an assembly binding redirect:
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
Assembly manager loaded from: C:WindowsMicrosoft.NETFrameworkv4.0.30319clr.dll
Running under executable C:Windowssyswow64Windowspowershellv1.0powershell.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = MYDOMAIN estuser
LOG: DisplayName = OutlookHelper.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5e4553dc0df45306
(Fully-specified)
LOG: Appbase = file:///C:/Windows/syswow64/Windowspowershell/v1.0/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = powershell.exe
Calling assembly : OutlookHelper.Data.Common, Version=1.0.5295.26925, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:Windowssyswow64Windowspowershellv1.0powershell.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:WindowsMicrosoft.NETFrameworkv4.0.30319configmachine.config.
LOG: Redirect found in application configuration file: 1.0.0.0 redirected to 2.0.0.0.
LOG: Post-policy reference: OutlookHelper.Common, Version=2.0.0.0, Culture=neutral, PublicKeyToken=5e4553dc0df45306
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Windows/syswow64/Windowspowershell/v1.0/OutlookHelper.Common.DLL.
LOG: Attempting download of new URL file:///C:/Windows/syswow64/Windowspowershell/v1.0/OutlookHelper.Common/OutlookHelper.Common.DLL.
LOG: Attempting download of new URL file:///C:/Windows/syswow64/Windowspowershell/v1.0/OutlookHelper.Common.EXE.
LOG: Attempting download of new URL file:///C:/Windows/syswow64/Windowspowershell/v1.0/OutlookHelper.Common/OutlookHelper.Common.EXE.
LOG: Attempting download of new URL file:///D:/SampleApps/_Common/Bin/Outlook.Extensions.Sample/OutlookHelper.Common.DLL.
LOG: Assembly download was successful. Attempting setup of file: D:SampleApps\_CommonBinOutlook.Extensions.SampleOutlookHelper.Common.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: OutlookHelper.Common, Version=2.0.0.0, Culture=neutral, PublicKeyToken=5e4553dc0df45306
LOG: Where-ref bind Codebase does not match what is found in default context. Keep the result in LoadFrom context.
LOG: Binding succeeds. Returns assembly from D:SampleApps\_CommonBinOutlook.Extensions.SampleOutlookHelper.Common.dll.
LOG: Assembly is loaded in LoadFrom load context.
以下是 Powershell 关于程序集标识的说明:
Here is what Powershell says about the assembly identity:
Windows PowerShell (x86)
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
PS C:Users estuser> ([xml](gc $([System.AppDomain]::CurrentDomain.SetupInformation.ConfigurationFile))).configuratio
n.runtime.assemblyBinding.dependentAssembly.assemblyIdentity
name publicKeyToken
---- --------------
OutlookHelper.Common 5e4553dc0df45306
PS C:Users estuser>
麻烦就从这里开始...
在 64 位机器上运行时，使用Windows Powershell"不起作用.程序集管理器未找到程序集绑定重定向:
This is where the trouble starts...
When running on a 64-bits machine, using 'Windows Powershell' it does not work. The assembly manager does NOT find the assembly binding redirect:
The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.
Assembly manager loaded from: C:WindowsMicrosoft.NETFramework64v4.0.30319clr.dll
Running under executable C:WINDOWSsystem32WindowsPowerShellv1.0powershell.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = MYDOMAIN estuser
LOG: DisplayName = OutlookHelper.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5e4553dc0df45306
(Fully-specified)
LOG: Appbase = file:///C:/WINDOWS/system32/WindowsPowerShell/v1.0/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = powershell.exe
Calling assembly : OutlookHelper.Data.Common, Version=1.0.5295.26925, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:WINDOWSsystem32WindowsPowerShellv1.0powershell.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:WindowsMicrosoft.NETFramework64v4.0.30319configmachine.config.
LOG: Post-policy reference: OutlookHelper.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5e4553dc0df45306
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).
以下是 Powershell 关于程序集标识的说明:
Here is what Powershell says about the assembly identity:
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
PS C:Users estuser> ([xml](gc $([System.AppDomain]::CurrentDomain.SetupInformation.ConfigurationFile))).configuratio
n.runtime.assemblyBinding.dependentAssembly.assemblyIdentity
PS C:Usersccontent01>
当我让 Powershell 获取它自己的应用程序配置文件的内容时，我得到以下输出:
When I let Powershell get the contents of its own application configuration file I get the following output:
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
PS C:Users estuser> gc C:WINDOWSsystem32WindowsPowerShellv1.0powershell.exe.Config
<?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
PS C:Users estuser>
我尝试了什么...
- 检查特定版本"是否设置为假"-> 是这种情况.
- 删除并重新添加应用程序配置文件 -> 没有修复它.
- 从 SysWOW64 文件夹中的新应用程序配置文件开始 -> 没有修复它.
- 仔细检查加载的文件的内容(powershell.exe.Config 和 machine.config)-> 它们是相同的.
- 程序集管理器找不到程序集重定向绑定.
- 为什么 64 位实例的 Fusion 日志没有提及在应用程序配置文件中找到重定向:1.0.0.0 重定向到 2.0.0.0"之类的内容?
- 这一切的原因是什么?
- 你能想到什么解决方案吗?
推荐答案
在 64 位机器上有两个配置文件:
On a 64-bit machine there are two configuration files:
C:Windowssystem32WindowsPowerShellv1.0powershell.exe.Config
C:Windowssyswow64Windowspowershellv1.0powershell.exe.Config
你在 64 位机器上编辑过它们吗?
Have you edited both of them on the 64-bit machine?
在 64 位版本的 Windows 上.32 位进程(如记事本++)由操作系统透明地从 C:WINDOWSSystem32 重定向到 C:WINDOWSSysWOW64.
On 64-bit versions of Windows. 32 bit processes (like notepad++) are transparently redirected from C:WINDOWSSystem32 to C:WINDOWSSysWOW64 by the OS.
您需要确保使用 64 位文本编辑器(如内置的 notepad.exe)编辑这两个文件.这将保证您不会遇到这个微妙的问题，这可能会导致混淆.
You will need to make sure you edit both files using a 64-bit text editor like the builtin notepad.exe. This will guarantee you do not suffer from this subtle issue, which can cause confusion.
这篇关于Powershell - 在应用程序配置文件中未找到程序集绑定重定向的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
