Question

I have an assembly on a shared folder (UNC-path only, no mapped drive). When I try to register it programmatically via RegistrationServices, I’m getting a strange error.

Here’s the code:

using System;
using System.IO;
using System.Reflection;
using System.Runtime.InteropServices;

namespace BLRegisterAssembly
{
    public static class BlRegisterAssembly
    {
        public static void Register()
        {
            var asm = Assembly.LoadFile(@"\\myUNCPath\myAssembly.dll");
            var rs = new RegistrationServices();
            rs.RegisterAssembly(asm, AssemblyRegistrationFlags.SetCodeBase);
            // I've also tried AssemblyRegistrationFlags.None : same error.
        }
    }
}

This is the error I’m getting:

“Could not load file or assembly
‘[xxxxxxxxxxxxx],
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=[xxxxxxxxxxxxxx]’ or
one of its dependencies. The system
cannot find the file specified.”

(The file in question is a referenced assembly that the main assembly uses).

Some more points:
– the referenced assembly is located in the same folder as the main assembly that I’m trying to register.
– the folder cannot be mapped as a logical drive. Because of how the network folders are accessed, users in different groups have different drive mappings to the same network folders, and these cannot be modified, per IT policy…

Can anyone point me in the right direction to resolve the problem?

ANSWERED
Because I was using Assembly.LoadFile, the dependent assemblies have to be resolved manually via AssemblyResolve. The following code update fixed my woes:

public void Register()
{
    AppDomain.CurrentDomain.AssemblyResolve += 
      new ResolveEventHandler(CurrentDomain_AssemblyResolve);

    var asm = Assembly.LoadFile(Path.Combine(m_path, assemblyName));
    var rs = new RegistrationServices();
    rs.RegisterAssembly(asm, AssemblyRegistrationFlags.SetCodeBase);
}

static Assembly CurrentDomain_AssemblyResolve(object sender, 
  ResolveEventArgs args)
{
    //... code to resolve the path and load the dependent assembly...
}

Answer 1

You should never use LoadFile(), use LoadFrom() so the CLR has a shot at finding any dependent assemblies. If you still have trouble then use Fuslogvw.exe to get a trace of the assembly resolution attempt. The backup plan is to implement AppDomain.AssemblyResolve.