.NET Standard项目引用.NET 4.0第三方类库的实现方案咨询

Hey there, I’ve run into similar compatibility hurdles when migrating to .NET Core/Standard, so let’s walk through feasible solutions that keep your indirect calling requirement intact.

Option 1: Direct Conditional Reference with Compatibility Mode #

.NET Standard 2.0 has built-in compatibility with .NET Framework 4.0+ assemblies (as long as the DLL doesn’t use .NET Framework-exclusive APIs unavailable in .NET Standard). Your direct reference likely failed because you didn’t enable the framework compatibility flag. Here’s how to fix it:

1. Unload your SomeFramework project in Visual Studio, right-click and select Edit .csproj.
2. Add the following configuration to reference SomeExternal.dll and enable compatibility:

   <ItemGroup>
     <Reference Include="SomeExternal">
       <!-- Replace with the actual path to your SomeExternal.dll -->
       <HintPath>../path/to/SomeExternal.dll</HintPath>
       <Private>True</Private>
     </Reference>
   </ItemGroup>
   
   <PropertyGroup>
     <!-- Enables compatibility with .NET Framework assemblies for .NET Standard -->
     <EnableDefaultFrameworkAssemblies>true</EnableDefaultFrameworkAssemblies>
   </PropertyGroup>
   

3. Reload the project and rebuild.

Important Check: Verify that SomeExternal.dll doesn’t rely on .NET Framework-specific APIs like System.Web, non-cross-platform System.Drawing, or WPF/WinForms components. If it does, this option will break your ASP.NET Core app—use the wrapper approach below instead.

Option 2: Create a .NET Framework Wrapper Layer #

If SomeExternal.dll uses .NET Framework-exclusive features, a wrapper project acts as a bridge between your .NET Standard framework and the legacy DLL. Here’s how to set it up:

• Create a new .NET Framework 4.7.1 Class Library (name it something like SomeExternalWrapper). This version is compatible with both your .NET 4.7.1 App_1 and .NET Standard 2.0 SomeFramework.
• Add a direct reference to SomeExternal.dll in this wrapper project.
• Wrap all needed functionality from SomeExternal.dll into simple methods/classes that don’t expose .NET Framework-specific types. For example:

  public class ExternalServiceWrapper
  {
      public string GetExternalData(int id)
      {
          // Call the original SomeExternal.dll method here
          var externalClient = new SomeExternal.ExternalClient();
          return externalClient.FetchData(id);
      }
  }
  

• In your SomeFramework project, add a reference to SomeExternalWrapper. Now SomeFramework can call the wrapper instead of directly referencing SomeExternal.dll.
• Both App_1 and App_2 will work seamlessly: the wrapper runs natively on .NET Framework 4.7.1, and .NET Core will load it via the .NET Standard compatibility layer (note: this only works on Windows—Linux/macOS can’t run .NET Framework DLLs).

Option 3: Merge Assemblies with ILRepack (Last Resort) #

If licensing allows, you can merge SomeExternal.dll into SomeFramework.dll using a tool like ILRepack. This avoids reference issues entirely, but ensure you have permission to redistribute the merged assembly.

1. Install the ILRepack NuGet package in SomeFramework:

   Install-Package ILRepack
   

2. Configure your csproj to merge the assemblies on build (use a post-build event or the ILRepack MSBuild task).

Note: This approach hides the dependency but can cause conflicts if SomeExternal.dll has conflicting dependencies or requires specific loading contexts.

内容的提问来源于stack exchange，提问作者Anderson Matos