none
Network shared assembly problem RRS feed

  • Question

  • Hi,

    My desktop application needs to create objects from assemblies located on a network shared drive. These assemblies
    are COM visible which allows the application's CLR to create objects through COM. Everything works fine when these
    assemblies are local to my machine, but I get an exception (COR_E_TARGETINVOCATION) when they are located on a network
    drive. The workaround I found is to give a strong-name key to these assemblies and to register them on the local machine's
    GAC. I'd like to avoid that.

    Is there a more easy way to support network shared assemblies ? How can I tell .NET to trust these assemblies without having them registered in the local GAC ? 

    thanks for the help.

    -mab

    Here's an example of an assembly binding log:

    *** Assembly Binder Log Entry  (8/30/2008 @ 8:56:58 AM) ***

    The operation was successful.
    Bind result: hr = 0x0. The operation completed successfully.

    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
    Running under executable  s:\Sicore\Debugamd64\bin\XSI.exe
    --- A detailed error log follows.

    === Pre-bind state information ===
    LOG: User = AVIDWW\mbelzile
    LOG: DisplayName = CSharpScripting
     (Partial)
    LOG: Appbase = file://lobby/PUBLIC/mab-workgroup/Application/Plugins/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = NULL
    Calling assembly : (Unknown).
    ===
    LOG: This bind starts in default load context.
    LOG: Download of application configuration file was attempted from file:///s:/Sicore/Debugamd64/bin/XSI.config.
    LOG: Configuration file s:\Sicore\Debugamd64\bin\XSI.config does not exist.
    LOG: No application configuration file found.
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
    LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
    LOG: Attempting download of new URL file://lobby/PUBLIC/mab-workgroup/Application/Plugins/CSharpScripting.DLL.
    LOG: Assembly download was successful. Attempting setup of file: file://lobby/PUBLIC/mab-workgroup/Application/Plugins/CSharpScripting.dll
    LOG: Entering run-from-source setup phase.
    LOG: Assembly Name is: CSharpScripting, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b7a610fae2122128
    LOG: A partially-specified assembly bind succeeded from the application directory. Need to re-apply policy.
    LOG: No application configuration file found.
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
    LOG: Post-policy reference: CSharpScripting, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b7a610fae2122128
    LOG: GAC Lookup was unsuccessful.
    LOG: Binding succeeds. Returns assembly from file://lobby/PUBLIC/mab-workgroup/Application/Plugins/CSharpScripting.dll.
    LOG: Assembly is loaded in default load context.

    Saturday, August 30, 2008 1:25 PM

All replies

  • Registering COM components that live on a mapped drive letter was not a well supported scenario even back in the COM days.  The odds that the drive letter mapping would still be available after the component got registered are low in general, zippo when another user tries to use it.

    But the specific problem you might be running in right now is that .NET doesn't trust code that gets loaded from a network share.  You'll have to tell it that you actually trust it by running Caspol.exe on every machine that tries to use the component.  The versioning problems with COM components pretty much requires you having to install it in the GAC however.

    Hans Passant.
    Sunday, August 31, 2008 10:23 PM
    Moderator
  • So I tried this for upgrading the policy level of my network shared assembly:

    c:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol -q -m -ag 1.2 -url \\lobby\PUBLIC\mab-workgroup\Application\Plugins\* FullTrust -n \\lobby\PUBLIC\mab-workgroup\Application\Plugins -d "Fulltrust granted to: \\lobby\PUBLIC\mab-workgroup\Application\Plugins"

    But as you pointed out this is not enough to allow the creation of objects from a network shared assembly. What is the use of modifying the assembly's security policy then if I still need to install it in the gac ? 

    thanks for your help.
    -mab

    Tuesday, September 2, 2008 1:21 PM