PowerShell的 - 集绑定重定向应用程序配置文件未找到 [英] Powershell - Assembly binding redirect NOT found in application configuration file

问题描述

我有一个PowerShell命令在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.

PowerShell命令，提及OutlookHelper.Common.dll。最新的版本是2.0.0.0 该cmdlet也使用记录和参考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:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Windows\syswow64\Windowspowershell\v1.0\powershell.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = MYDOMAIN\testuser
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:\Windows\syswow64\Windowspowershell\v1.0\powershell.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.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\_Common\Bin\Outlook.Extensions.Sample\OutlookHelper.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\_Common\Bin\Outlook.Extensions.Sample\OutlookHelper.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\testuser> ([xml](gc $([System.AppDomain]::CurrentDomain.SetupInformation.ConfigurationFile))).configuratio
n.runtime.assemblyBinding.dependentAssembly.assemblyIdentity

name                                                        publicKeyToken
----                                                        --------------
OutlookHelper.Common                                        5e4553dc0df45306

PS C:\Users\testuser>

这是麻烦的开始...

在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:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = MYDOMAIN\testuser
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:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.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\testuser> ([xml](gc $([System.AppDomain]::CurrentDomain.SetupInformation.ConfigurationFile))).configuratio
n.runtime.assemblyBinding.dependentAssembly.assemblyIdentity
PS C:\Users\ccontent01>

当我让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\testuser> gc C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.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\testuser>

我试了...

• 检查特定版本是否设置为假 - >是这样
• 删除并重新添加应用程序配置文件 - >没有解决它
。
• 入门的Syswow64资料夹的新应用程序配置文件 - >没有解决它
• 双击选中已加载的文件的内容（powershell.exe.Config和machine.config中） - >它们是相同的
。

What I tried...

• Check whether 'Specific Version' is set to 'false' -> this is the case.
• Deleted and re-added the application configuration file -> did not fix it.
• Started with a new application configuration file in the SysWOW64 folder -> did not fix it.
• Double checked the contents of the files that are loaded (powershell.exe.Config and machine.config) -> they are the same.
• 在大会管理器无法查找程序集重定向结合。
• 为什么融合日志的64位实例没有提到类似重定向发现，应用程序配置文件：1.0.0.0重定向到2.0.0.0'？
• 什么是这一切的？
的原因
• 您能想到的任何解决方案？

推荐答案

在64位机有两个配置文件：

On a 64-bit machine there are two configuration files:

C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe.Config
C:\Windows\syswow64\Windowspowershell\v1.0\powershell.exe.Config

你有没有在64位计算机上编辑他们两个？

Have you edited both of them on the 64-bit machine?

在64位版本的Windows。 32位进程（如记事本+ +）是透明地从C重定向：\ WINDOWS \ System32下为C：\ WINDOWS \ Syswow64资料由OS

On 64-bit versions of Windows. 32 bit processes (like notepad++) are transparently redirected from C:\WINDOWS\System32 to C:\WINDOWS\SysWOW64 by the OS.

您将需要确保你使用像内建NOTEPAD.EXE 64位的文本编辑器编辑这两个文件。这将保证你不从这个微妙的问题，这可能会导致混乱受到影响。

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屋！