PowerShell核心：解决集会冲突

Question

我发现了一个有趣的案例，我无法完全理解。

我的运行时 - PowerShell 7.2.4

我有两个PowerShell核心模块： net6powershellmodule 和 netStandstandArdPowersHellModule 。

---

net6powershellmodule.csproj ：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

  <ItemGroup>
    <None Remove="Net6PowerShellModule.psd1" />
  </ItemGroup>

  <ItemGroup>
    <Content Include="Net6PowerShellModule.psd1">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="6.0.0" />
    <PackageReference Include="System.Management.Automation" Version="7.2.4" />
  </ItemGroup>
</Project>

test net6cmdlet.cs

using System.Management.Automation;

namespace Net6PowerShellModule
{
    [Cmdlet("Test", "Net6Cmdlet")]
    public class TestNet6Cmdlet : PSCmdlet
    {
        protected override void ProcessRecord()
        {
            var type = typeof(Microsoft.Extensions.DependencyInjection.IServiceCollection);

            WriteObject("Net6 Cmdlet Run.");
        }
    }
}

net6powershellmodule.psd1

@{
    RootModule = 'Net6PowerShellModule.dll'
    ModuleVersion = '0.0.1'
    GUID = '8c1bd929-32bd-44c3-af6b-d9dd261e34f3'
    CmdletsToExport = 'Test-Net6Cmdlet'
}

---

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

  <ItemGroup>
    <None Remove="NetstandardPowerShellModule.psd1" />
  </ItemGroup>

  <ItemGroup>
    <Content Include="NetstandardPowerShellModule.psd1">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="2.2.0" />
    <PackageReference Include="System.Management.Automation" Version="6.1.2" />
  </ItemGroup>
</Project>

net standstandArdPowerShellModule.csproj.csproj ： 。

using System.Management.Automation;

namespace NetstandardPowerShellModule
{
    [Cmdlet("Test", "NetstandardCmdlet")]
    public class TestNetstandardCmdlet : PSCmdlet
    {
        protected override void ProcessRecord()
        {
            var type = typeof(Microsoft.Extensions.DependencyInjection.IServiceCollection);

            WriteObject("Netstandard 2.0 Cmdlet Run.");
        }
    }
}

​

@{
    RootModule = 'NetstandardPowerShellModule.dll'
    ModuleVersion = '0.0.1'
    GUID = 'eef615d0-aecf-4e89-8f4c-53174f8c99d6'
    CmdletsToExport = 'Test-NetstandardCmdlet'
}

---

​

1. ​
2. ​
3. ​test-net6cmdlet
4. 运行 test-netstandardcmdlet

结果 - 一切都正确运行。唯一的加载程序集是 microsoft.extensions.dependentiondoction.abstractions 版本 6.0.0 。

---

1. 导入 net6powershellmodule
2. import netstandstandardpowershellmodule
3. 运行 test-netstandstandardcmdlet
4. 运行 test-net6cmdlet 。

结果 - 错误： test net6cmdlet：无法加载文件或汇编'microsoft.extensions.dependencyIndoction.Abstractions，版本= 6.0.0.0，culture =中性=中性，public Keytoken = adb9793829dddae60'。找不到或加载特定文件。 （0x80131621）

---

基于这个问题，这不是一个预期的行为：

随后的尝试加载不同版本的汇编： 在PowerShell（Core）7+中导致语句终止错误 带有相同名称的汇编已加载。

为什么第一个方案工作？

---

如果我添加 quired Assemblies = @（'microsoft.extensions.dependentionspoction.abstractions.dll.dll'） line line在两个模块表现中，我都有一个预期的行为：不管先加载哪个模块，我仍然得到错误：带有同名的汇编已经加载。

---

更新1

我已经看过的文章：

• https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat /nesion-dipendenty-conflicts
• powerShell：为什么我能够在一个会话中加载多个版本的同一.NET组件，也可以“绕过依赖性地狱”？
• https：//devblogs.microsoft.com/powers.com/powershell/resolving-powershell/resolving-powershell-module-module-module-module-modelend-conpelency-conflict-conflicts-conflicts/ << /a> - 本文解释了有关汇编负载上下文的很多解释，但是我仍然无法理解 requientsemblies 在 .psd1 文件中定义的差异或使用代码中的依赖项。

Answer 1

tl; dr

• 在创作模块时，最好使用 模块清单（ .psd1 file），带有 quiends> quiendsAssemblies 要声明依赖（helper）组件的键 /strong>，因为它使此类组件的加载可预测的，，因为它在模块导入时发生。
  

  
  

  • 在 Windows PowerShell 中，尝试加载已经加载的已经加载的汇编的不同版本的尝试被安静地忽略，并使新导入的模块用于使用< em>也已经加载了汇编，可以或可能不起作用。

  • in powershell（core） （v6+），尝试加载已经加载的已经加载的组件的不同版本的尝试是 。

    。
    

  
  

  
  

• 如果您使用 intemit 基于.NET的机制的依赖组件的加载，则无法保证这些依赖关系的时机，并且在PowerShell（core）中，您将绕过防止尝试加载已经加载的已经加载的程序集的不同版本的检查 - 它可能有效，也可能不起作用，并且只有在以后的加载尝试请求 版本的情况下才允许。<<<<<<<<<<<< /p>
  

• 非平凡的解决方法可靠 给定组件的不同版本并排 。

  。
  

---

背景信息

之一您的链接之一，解决powershell模块组件依赖性冲突，包含所有相关信息，但它是一本带有复杂，深入的信息的冗长读取，并且无法阐明 powerShell的方式）（v6+）< / em>覆盖了基础.NET（CORE） / .NET 5+框架的行为。

术语：为简单起见，我将使用以下术语：

• Windows PowerShell 是遗产，船只，备用窗口的Windows-Windows-PowerShell，其最新和最新的版本最终版本为5.1.x。

  • 它建在 .net Framework的顶部，遗产，仅Windows的.NET，其最新版本和最后版本是v4.8.x

  
  

  
  

• powerShell core （现在正式出现 powershell ）是现代的，跨平台的，按需安装的powershell版本，其第一个（但现在过时的）版本为v6，其当前版本为v7 .2.6。

  • 它建立在 .net core 的顶部（正式是因为V5 Just .net ），现代的，跨平台的，安装的按需版本。网。

基本问题< / strong>：

• 在.NET框架 / CLR（通用语言运行时）级别，基本问题是无法并排加载不同版本的不同版本相同应用域（.net Framework）/ alc （ assembly-load-load上下文，.net core）：将的第一个加载到会话中悄悄地赢得，而.NET核心施加了额外的限制，即仅尝试加载下下版本成功（见下文）。

  
  

• PowerShell仅使用单个应用程序域 / ALC，包括用于模块，需要解决方案< / strong>才能并排的不同版本的A（依赖）组件。链接的文章详细介绍了各种解决方法； 强大的，通用的，进程的解决方法需要Powershell核心，并且仅限于 binary （编译）模块，并且是非平凡的;有限的解决方法，一些程序外，可用于Windows PowerShell和Cross-Powershell-Edition代码。

  
  

行为没有解决方法：

• Windows PowerShell和.NET框架：

  在已加载版本，，不考虑要求的版本高还是更低与已经加载的版本相比。
  • 奇怪的是，当呼叫者使用反射带有 typeof 来检查装配及其刚加载的类型（无论是隐式还是明确），请求请求汇编版本已报告 - 即使它是已经加载的汇编及其类型实际上是 。

  • Windows PowerShell确实 使用自定义功能覆盖此行为，尽管您是否使用模块清单（ .psd1 ） file）带有 essircealsemblies 输入可以在上有所作为依赖依赖的组件（请参见下文）。

    。

  • UPSHOT ：

    • 尝试加载已加载的汇编的不同版本永不失败，让呼叫者使用已加载的版本。

    • 此可能会或可能不工作，您只会在相关组件中的类型时注意到 （构建实例，属性访问，方法调用，...）。

      • 值得注意的是，如果以后的呼叫者试图加载a 更高> 版本的 fail ，因为它可能依赖于已经加载的较低的功能版本没有，但是即使是逆场景也不能成功，鉴于更高版本可能引入了破坏更改。

    
    

    
    

  
  

  
  

• PowerShell Core和.net Core ：

  • .net core ：

    • 悄悄忽略随后的尝试加载已经加载的汇编的A 下版本，并且使呼叫者使用已经加载的版本< /em>

      
      

    • 抛出异常，以尝试加载A 更高> 版本：无法找到或加载特定文件。 （0x80131621）

    • 基本原理似乎是：一个已经加载的更高版本至少是可能可能 be em>向后兼容请求的较低版本 - 尽管在没有用于.net组件的语义版本的情况下 - 这是不保证的。

      
      

    • 当不例外时做请参阅实际，已经加载的汇编版本 - 与.NET Framework不同。

    
    

  
  

  • powershell core 用自定义功能覆盖了此行为，与Windows PowerShell不同：

    • 它定义了针对插件的自定义依赖处理程序 [system.reflection.sembly] :: loadfrom（） .net core api，它在以下情况下使用了场景：

      • 使用模块清单加载模块时（ .psd1 ），该模块通过其 essirte> quilt> essirtageAssemblies entry

        来声明依赖的汇编。

      • 呼叫 带有 -path / -literalPath 。

      • 在中使用汇编语句。

    • 此自定义依赖性分辨率处理程序 明确地预防尝试加载已经加载的版本的不同版本，无论哪个版本编号更高。

      • 语句 - 终止带有同名的汇编已经加载错误（在使用assembly 的情况下，在的情况下，加载脚本在解析阶段中断，带有> 无法加载汇编'...'）。

      


      


    


    


  • UPSHOT ：

    • 在PowerShell Core中，尝试加载已加载的汇编的不同版本总是失败，如果您让 powershell 进行负载尝试。

      • 仅当您使用.net core的隐式依赖项加载时，偶然的机会 即可成功，即如果尝试加载a << em> lower 版本以后。隐式依赖加载会自动发生，通过 .NET API，该API基于提供依赖的汇编（位于位置独立于位置）全名和默认探测路径寻找托管 file ，它特别包括调用汇编本身的目录。

      • 此可能会或可能不工作，鉴于.net组件的版本使用不使用 smentical 版本，因此又有更高版本的汇编版本是' t 保证向后兼容。

        
        

      • 另外，依赖依赖的隐式加载的正时是无法预测的，通常直到所讨论的组件的类型实际上是使用使用 （构建实例，属性访问，方法调用等等）。因此，如果您依靠模块使用隐式依赖性加载，则在导入模块与何时尝试进行实际依赖性加载之间没有保证的关系，因此，如果具有a lows 版本恰好是在给定的会话中加载的第一个（但是，如前所述，即使首先加载了较高的版本，您也可能会看到以后的错误。 em>）。