none
Assembly.Load fails when loading from network share RRS feed

  • Question

  • Hi.

    My application is running from the local drive. I'm trying to load an assembly from the network share at run-time, using UNC path. Here's the code:

                    var codeBase = @"\\server\share\Plugin1.dll";
                    var assemblyName = AssemblyName.GetAssemblyName(codeBase);
                    var assembly = Assembly.Load(assemblyName);
    

    Assembly.Load fails with this exception:

    Could not load file or assembly 'Plugin1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c948a91116bde48d' or one of its dependencies. The system cannot find the file specified.

    If I use Assembly.LoadFrom with this settings in app.config:

      <runtime>
        <loadFromRemoteSources enabled="true" />
      </runtime>
    
                    var codeBase = @"\\server\share\Plugin1.dll";
                    var assembly = Assembly.LoadFrom(codeBase); 
    

    it works, but it is not the best way - to use LoadFrom method.

    Also,

    loadFromRemoteSources

    has no effect for Assembly.Load.

    .NET version is 4.0.

    Is this happening because of any security settings? How to solve this problem?

    Thursday, February 2, 2012 12:49 PM

Answers

  • If the path is correct then the problem may lie in the assemblies dependencies. Have you traced it with the Fusion Logger to see if it's failing because it can't find a dependency?
    • Marked as answer by Paul Zhou Thursday, February 16, 2012 8:51 AM
    Thursday, February 2, 2012 7:37 PM
  • Jared,

    if the problem is in dependencies, LoadFrom would fail too, isn't it?

    <snip>

    2) This line of code executes successfully:

    var assemblyName = AssemblyName.GetAssemblyName(codeBase);

    It gets a public key token, version -> it finds the assembly file.


    GetAssemblyName() isn't the same as a Load, even it finds the assembly. I bet it uses GetAssemblyIdentityFromFile etc.

    It's also worth checking a few boring things, such as whether there's already a copy of that assembly in your GAC, or elsewhere because Load will go there first. That will really confuse things because (quoting docs):

    "FileLoadException is thrown if assemblyString specifies the full assembly name, and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name. "

    +1 on using the Fusion Logger - that is exactly what this tool is for.

     

     


    Phil Wilson
    • Marked as answer by Paul Zhou Thursday, February 16, 2012 8:51 AM
    Thursday, February 2, 2012 9:02 PM

All replies

  • Why do you think LoadFrom is not best way?


    Please mark this post as answer if it solved your problem. Happy Programming!
    Thursday, February 2, 2012 12:53 PM
  • Adavesh,

     

    because it's easy to load an assembly twice from the different locations. I don't want to look into the reason of exception messages like "Unable to cast 'MyType' to 'MyType'". E.g., see this post: http://geekswithblogs.net/rupreet/archive/2010/02/16/137988.aspx.

     

    Thursday, February 2, 2012 1:09 PM
  • I have tried the above and Assembly.Load works without any problem. Just make sure about the path if its accessible. Try to paste  \\server\share in windows explorer and you should see your dll in that folder.

    When I entered a wrong path I got the same error message "Could not load....."

     


    Rajesh S V
    Thursday, February 2, 2012 3:07 PM
  • Rajesh,

    The path is correct.

     

    Thursday, February 2, 2012 7:08 PM
  • If the path is correct then the problem may lie in the assemblies dependencies. Have you traced it with the Fusion Logger to see if it's failing because it can't find a dependency?
    • Marked as answer by Paul Zhou Thursday, February 16, 2012 8:51 AM
    Thursday, February 2, 2012 7:37 PM
  • Jared,

    if the problem is in dependencies, LoadFrom would fail too, isn't it?

    Besides:

    1) Plugin1.dll has dependencies from assemblies that have been loaded already.

    2) This line of code executes successfully:

    var assemblyName = AssemblyName.GetAssemblyName(codeBase);

    It gets a public key token, version -> it finds the assembly file.

     

     

     


    Thursday, February 2, 2012 7:50 PM
  • Jared,

    if the problem is in dependencies, LoadFrom would fail too, isn't it?

    <snip>

    2) This line of code executes successfully:

    var assemblyName = AssemblyName.GetAssemblyName(codeBase);

    It gets a public key token, version -> it finds the assembly file.


    GetAssemblyName() isn't the same as a Load, even it finds the assembly. I bet it uses GetAssemblyIdentityFromFile etc.

    It's also worth checking a few boring things, such as whether there's already a copy of that assembly in your GAC, or elsewhere because Load will go there first. That will really confuse things because (quoting docs):

    "FileLoadException is thrown if assemblyString specifies the full assembly name, and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name. "

    +1 on using the Fusion Logger - that is exactly what this tool is for.

     

     


    Phil Wilson
    • Marked as answer by Paul Zhou Thursday, February 16, 2012 8:51 AM
    Thursday, February 2, 2012 9:02 PM
  • >GetAssemblyName() isn't the same as a Load

    Yes, I know. I've made an example with GetAssemblyName to show that assembly file is physically available for my executable. Assembly does not present in GAC or elsewhere.

    Here's the Fusion Logger's log for this assembly:

    1) This log is from "default" folder:

     

    *** Assembly Binder Log Entry  (03.02.2012 @ 10:05:12) ***
    
    The operation failed.
    Bind result: hr = 0x80070002. The system cannot find the file specified.
    
    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable  D:\PROJECTS\Research\Solution1\Debug\MefHostApp.vshost.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: User = DENNIS64\petrov
    LOG: DisplayName = Plugin1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c948a91116bde48d, processorArchitecture=MSIL
     (Fully-specified)
    LOG: Appbase = file:///D:/PROJECTS/Research/Solution1/Debug/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = MefHostApp.vshost.exe
    Calling assembly : MefHostApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
    ===
    LOG: This bind starts in default load context.
    LOG: Using application configuration file: D:\PROJECTS\Research\Solution1\Debug\MefHostApp.vshost.exe.Config
    LOG: Using host configuration file: 
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG: Post-policy reference: Plugin1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c948a91116bde48d, processorArchitecture=MSIL
    LOG: GAC Lookup was unsuccessful.
    LOG: Attempting download of new URL file:///D:/PROJECTS/Research/Solution1/Debug/Plugin1.DLL.
    LOG: Attempting download of new URL file:///D:/PROJECTS/Research/Solution1/Debug/Plugin1/Plugin1.DLL.
    LOG: Attempting download of new URL file:///D:/PROJECTS/Research/Solution1/Debug/Plugin1.EXE.
    LOG: Attempting download of new URL file:///D:/PROJECTS/Research/Solution1/Debug/Plugin1/Plugin1.EXE.
    LOG: All probing URLs attempted and failed.
    

     

    2) And this is from the "native images" folder:

     

    *** Assembly Binder Log Entry  (03.02.2012 @ 10:05:12) ***
    
    The operation failed.
    Bind result: hr = 0x80070002. The system cannot find the file specified.
    
    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable  D:\PROJECTS\Research\Solution1\Debug\MefHostApp.vshost.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: User = DENNIS64\petrov
    LOG: DisplayName = Plugin1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c948a91116bde48d, processorArchitecture=MSIL
     (Fully-specified)
    LOG: Appbase = file:///D:/PROJECTS/Research/Solution1/Debug/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = MefHostApp.vshost.exe
    Calling assembly : MefHostApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
    ===
    LOG: Start binding of native image Plugin1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c948a91116bde48d, processorArchitecture=MSIL.
    WRN: No matching native image found.
    
    

    So, it happens that Assebmly.Load just ignores AssemblyName.Codebase. There's no attempt to load file from "\\server\share" path.

     

    OMG, this is very unexpected behavior... (

     

     

     


    Friday, February 3, 2012 6:40 AM
  • Can you try to copy the dll into the local machine and try to load it from a different path and see if you get the same error. Also worth checking if you have read/write permissions on the location where you are trying to load the assembly from. 


    Rajesh S V
    Friday, February 3, 2012 9:52 AM
  • Of course I can.

    If there were problems with network path/permissions, LoadFrom would fail too.

     

    I can say that problem is solved.

    Fusion logs and "CLR via C#" tells us that it is normal behavior for the Load method. Workaround for this situation is to make separate probing path, include it in the app.config and download there assemblies from share, when an application needs to load them. Then, application must use Assembly.Load.

     

    Topic can be closed.

    Friday, February 3, 2012 10:02 AM
  • Topics don't generally close on the msdn/TechNet forums (technically they can be locked if a conversation needs moderation). What's supposed to happen is the user who started the thread will mark the most helpful post (the one that lead them to solving their problem) as the answer.
    Friday, February 3, 2012 5:36 PM