无需GAC，在自定义WMI类中引用第三方.dll文件

Absolutely, you can make WMI load your third-party DLL straight from C:\Test without having to mess with GAC registration or tools like gacutil/installutil. Let’s break down how to do this and explain the underlying mechanism:

Yes, totally. You don’t need to register the DLL in the GAC or run installation utilities—you can explicitly tell your custom WMI provider to use the DLL from C:\Test directly. Here are the two most reliable approaches:

1. Explicitly load the DLL in your WMI provider code #

When building your custom WMI class (a managed provider), use .NET’s assembly loading methods to pull in something.dll at runtime. For example:

// Add this in your WMI provider's initialization logic
Assembly externalAssembly = Assembly.LoadFrom(@"C:\Test\something.dll");
Type targetClass = externalAssembly.GetType("YourNamespace.TargetClassName");
object classInstance = Activator.CreateInstance(targetClass);

This method skips the default GAC and system path search entirely, ensuring WMI uses the exact DLL you specify. Use Assembly.LoadFrom() if the DLL has dependencies that need resolution (it will look in the same directory for dependent files), or Assembly.LoadFile() if you only want to load the specific DLL without resolving dependencies.

2. Use private probing paths (if your provider DLL is in a shared location) #

If your WMI provider’s own DLL is stored in a standard location like %systemroot%\system32\wbem, you can add a configuration file to tell .NET where to look for private assemblies. Create a file named YourProviderDllName.dll.config in the same directory as your provider DLL, with this content:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="C:\Test"/>
    </assemblyBinding>
  </runtime>
</configuration>

This tells the .NET runtime to check C:\Test for any dependent assemblies that aren’t found in the GAC or default paths. Note this only works if your provider references the external DLL as a dependent assembly (i.e., it’s listed in your provider’s manifest).

WMI follows .NET’s standard assembly loading rules for managed providers, but with a few WMI-specific quirks:

• Default search order: WMI first checks the GAC, then the %systemroot%\system32\wbem directory (the default home for WMI providers), then the current working directory of the WMI service.
• Explicit loading overrides: When you use Assembly.LoadFrom() or LoadFile() in your provider code, you take full control—WMI will use the assembly you load, ignoring the default search path.
• Service permissions: The WMI service (running as Winmgmt, usually under LOCAL SERVICE or NETWORK SERVICE) needs read access to C:\Test. If it doesn’t have permission, the assembly load will fail silently—check the WMI-Activity event log in Event Viewer for detailed errors.

• Avoid GAC conflicts: If a version of something.dll exists in the GAC, .NET might prioritize it over your local copy unless you explicitly load the local DLL. Using LoadFrom() is the safest way to bypass this.
• Dependency handling: If something.dll has its own dependencies, make sure they’re either in C:\Test (so LoadFrom() can find them) or explicitly loaded in your code.
• Debugging: If the DLL fails to load, check the WMI-Activity log under Event Viewer > Applications and Services Logs > Microsoft > Windows > WMI-Activity—it will include detailed error messages like missing files or permission problems.

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