WCF应用加载EX.DLL失败，控制台应用正常的排查求助

Hey there, let's break down your problem step by step—this DLL loading headache is super common when moving code from console to WCF, and I've got some concrete steps to help you fix it.

First: Why WCF and Console Apps Load DLLs Differently #

You're right to suspect a difference in loading mechanisms—here's the key breakdown:

• Console Apps: They load DLLs directly from the current working directory (usually your project's bin\Debug/bin\Release folder) using the standard desktop application context. The path is straightforward, and dependencies are easy to track because you're running the exe directly from the folder with all your DLLs.
• WCF Apps (IIS-Hosted):
  • IIS uses an application pool process (w3wp.exe) with its own working directory (typically your website's root, not the bin folder by default).
  • WCF leverages .NET's shadow copy feature by default, which copies DLLs from your bin folder to a temporary system directory (that's why you saw EX.DLL in temp files in your Fusion logs). Sometimes shadow copy fails to copy all dependencies, leaving gaps.
  • If a DLL is in the GAC (like your EM.DLL), WCF will prioritize loading it from the GAC over your local bin folder. But the GAC'd EM.DLL might expect its dependencies (like EX.DLL) to also be in the GAC or in IIS's probe paths—if they're not, you get the missing module error.

How to Find Exactly Which Dependency Is Missing #

You mentioned Dependency Walker and Fusion logs but didn't get clear results—let's fix that with targeted tools:

1. Use Visual Studio's Modules Window (Debugging) #

• Attach the debugger to your WCF process (w3wp.exe if IIS-hosted) when the exception occurs.
• Go to Debug > Windows > Modules to see all loaded assemblies.
• Look for EM.DLL and EX.DLL:
  • If they're not listed, note the paths the debugger tried to load them from.
  • If they are listed, expand their dependencies (right-click > "View Dependencies") to see which child DLLs are marked as "Not Loaded". That's your missing dependency.

2. Dig Deeper with Fusion Log Viewer #

• Open fuslogvw.exe (it's in your .NET Framework directory, e.g., C:\Windows\Microsoft.NET\Framework\v4.0.30319\fuslogvw.exe).
• Click Settings, select "Log bind failures to disk" and "Show all binds", then click OK.
• Reproduce the error, then refresh the viewer. Look for entries related to EX.DLL and its dependencies—each entry will list:
  • The exact DLL name/version it's trying to load.
  • All paths it probed (and failed to find the DLL in).
    This will tell you exactly which dependency is missing and where the runtime is looking for it.

3. Fix Dependency Walker Usage #

• Drag EX.DLL directly into Dependency Walker.
• Ignore any red entries for system DLLs starting with API-MS-WIN- or EXT-MS-WIN-—these are Windows API sets, not actual missing files.
• Focus on red entries for the 76 SDK DLLs—those are the real missing dependencies you need to copy to your WCF bin folder.

Targeted Fixes for Your Scenario #

Now that you can identify the missing dependency, here's how to resolve the loading issue:

1. Sync DLLs Between Console and WCF #

Since your console app works perfectly, copy all SDK-related DLLs (EM.DLL, EX.DLL, and the 76 supporting DLLs) from your console's output folder to your WCF app's bin directory. This ensures WCF has access to the exact same dependencies that work in the console.

2. Override GAC Priority #

Since EM.DLL is in the GAC (and causing conflicts), force WCF to use your local bin version:

• In your WCF project, right-click the EM.DLL reference > Properties.
• Set Copy Local to True and Specific Version to True (match the version you're using in the console).
• This tells the runtime to load the local DLL instead of the GAC'd one.

3. Disable Shadow Copy (If Needed) #

If shadow copy is causing dependencies to be missed in the temp directory, turn it off in your web.config:

<system.web>
  <hostingEnvironment shadowCopyBinAssemblies="false" />
</system.web>

4. Add Probing Paths to web.config #

If you keep SDK DLLs in a subfolder under bin, tell WCF to look there:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <probing privatePath="SDK;libs" /> <!-- Replace with your actual subfolder names -->
  </assemblyBinding>
</runtime>

Final Checks #

• After making changes, restart your IIS application pool to ensure all DLLs are reloaded.
• Double-check that no SDK DLLs are accidentally excluded from your WCF project's output (right-click the DLL in the project > Properties > set Copy to Output Directory to Copy if newer).

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