In Monad, mshsnapins can be installed in a different directory from the Monad executables. At runtime, the Monad engine will load the mshsnapin assembly and its referenced assemblies based on application base information provided during mshsnapin installation.

If an mshsnapin itself dynamically loads an assembly through an assembly name or a relative path, however, CLR may not be able to locate the assembly.  This is because the CLR runtime knows nothing about the mshsnapin installation directory and thus will not search there during dynamic assembly resolution. 

The following is a common scenario for this:  Assume that an mshsnapin named “mysnapin” is installed in the c:\mysnapin directory and the monad executable is installed in c:\monad\ directory. Also assume that cmdlet “my-command” in “mysnapin” will dynamically load another assembly like this, (assume mylibrary.dll sits in the same directory as “mysnapin” assembly)

Assembly.LoadFrom(“mylibrary.dll”);

If you run “my-command” in msh.exe, you will get an error indicating that mylibrary.dll can’t be found. The reason for this is that CLR runtime only searchs through the GAC and the currently executable directory (which is installation directory for msh.exe) for assembly resolution.

If you want to dynamically load an assembly in your mshsnapin, always provide an absolute path unless the assembly itself is in GAC.

-George[MSFT]

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]