none
regasm failed with HRESULT: 0x80131515

    Question

  • Hello,

    for registering our addin we use the following line in a batch file:

    "%WINDIR%\Microsoft.NET\Framework\v4.0.30319\regasm" /codebase /tlb Jedox.Palo.XlAddin.dll
    

    The batch file is executed in the directory where Jedox.Palo.XlAddin.dll is located.

    Some customer gets the following error although it is executed with admin rights :

    RegAsm : error RA0000 : Could not load file or assembly

    'file:///C:\Programme\Jedox\Jedox Suite\xladdin\Jedox.Palo.XlAddin.dll'

    or one of its dependencies.

    Operation is not supported. (Exception from HRESULT: 0x80131515)

     I know already that this happens with network drive,

    but here it looks like everything is local.

    So what can we do ?

     TIA

      Hendrik Schmieder

     

    Thursday, January 31, 2013 1:31 PM

Answers

  • There is an assembly mismatch on culture. When an assembly has a dependency on another assembly, the requirement is that the entire "assembbly name" matches, and that includes name, assembly version, culture, strong name. They all need to match.

    Phil Wilson

    Monday, February 25, 2013 6:49 PM

All replies

  • Hi Hendrik,

    Welcome to the MSDN Forum.

    To troubleshoot this issue, please follow the suggestion: http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/8dc14207-811e-47ca-b417-10eece61e7f4

    I assume the following:

    • You are using regasm.exe to register myplugin.dll, a managed application extension.
    • Your application calls to and has a dependency on Other.dll.
    • I assume that Other.dll is another managed assembly that is not accessed by COM Interop.

    You should look at the following options:

    • Option 1: Add a temporary or permanent strong name key to the Other.dll assembly and the load the assembly into the GAC.  The GAC is like the old Windows\System and WIndows\System32 directories for native dlls.  The assembly in this case should be easily found and publically available.  Then add a temporary or permanent strong name key to the myplugin.dll COM Interop assembly.  Load this into the GAC and then register the assembly with RegAsm.exe.
    • Option 2: Load both files into the same directory as private assemblies.  Then add a temporary or permanent strong name key to the myplugin.dll COM Interop assembly; this step is optional but recommended.  Register the myplugin.dll COM Interop assembly with RegAsm.exe, but use the /codebase switch.  It is when using this switch that Microsoft recommends using a strong named assembly.  This switch loads information about a private COM Interop assembly into the registry just as if you had loaded the assembly into the GAC.  This is like a GAC "go-find" to a private directory.
    • Option 3: Override option 1 and option 2 by forcing the running of a local or private assembly even though one has been registered with RegAsm.exe.  This requires the create of an empty file with notepad; you name this file as "myplugin.dll.local".  This file acts as a marker and tells the CLR to look for a local copy of the COM Interop DLL versus one that has been registered to the assembly.  This comes in handy during development.  This is known as SxS or using Side-By-Side assemblies for COM Interop.  Your registry may have become corrupted; so this is a good this to try out.
    • Option 4: Try using the /unregister switch with RegAsm.exe.  Sometimes this can fix or clear out bad information in the registry with having to manually do it.  Manual work on the assembly is not an easy task.  You might need to be conscious of where you registered your assemblies and use the same path to the DLL in unregistering the assembly with RegAsm.exe.  This is especially true if you altered the GUID on the components.
    • Option 5:  Last resort, not always good for the registry, but do change the GUID in the good and re-register the component.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, February 01, 2013 9:17 AM
  • Why can I not unmark an answer anymore ?

    Our customer had tried unregistering and then cleaning the regitry without success.

    So the reply did not solve the problem.

    The problem still exists !

    Thursday, February 07, 2013 12:49 PM
  • Hi Hendrik,

    It may be a forum issue, anyway, I have unmarked it.

    Thank you for telling us the situation on your side.

    Which assemblies does this DLL reference? Are them all in GAC?

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, February 08, 2013 4:38 AM
  • The original regasm is a more complicated example, but there also a less complicated one which also fails:

    "%WINDIR%\Microsoft.NET\Framework\v4.0.30319\regasm" /codebase /tlb PaloXlAddin2007.dll

    This are the references (from csproj file)

        <Reference Include="Extensibility, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
          <SpecificVersion>False</SpecificVersion>
          <EmbedInteropTypes>True</EmbedInteropTypes>
          <HintPath>..\..\XlAddin\signed\Extensibility.dll</HintPath>
        </Reference>
        <Reference Include="Microsoft.Office.Interop.Excel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL">
          <SpecificVersion>False</SpecificVersion>
          <EmbedInteropTypes>True</EmbedInteropTypes>
          <HintPath>..\..\XlAddin\signed\Microsoft.Office.Interop.Excel.dll</HintPath>
        </Reference>
        <Reference Include="Office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
          <HintPath>..\..\XlAddin\signed\Office.dll</HintPath>
          <SpecificVersion>False</SpecificVersion>
          <EmbedInteropTypes>True</EmbedInteropTypes>
        </Reference>
        <Reference Include="System">
          <HintPath>System.dll</HintPath>
          <Name>System</Name>
        </Reference>
        <Reference Include="System.Data">
          <HintPath>System.Data.dll</HintPath>
          <Name>System.Data</Name>
        </Reference>
        <Reference Include="System.Drawing" />
        <Reference Include="System.Management" />
        <Reference Include="System.Windows.Forms" />
        <Reference Include="System.XML">
          <HintPath>System.XML.dll</HintPath>
          <Name>System.XML</Name>
        </Reference>
    

    Friday, February 08, 2013 3:07 PM
  • Hi Schmieder,

    Welcome to the MSDN Forum.

    From this XML file, I see that you reference the local assembly : Extensibility, Excel, Office. Would you like to use the GAC assemblies instead of these local ones?

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, February 11, 2013 5:36 AM
  • Sorry for the delay.

    Since we can't reproduce the prblem locally why have to check with one of our customer.

    The customer uses german Windows XP ( german is important here).

    We enabled Fusionlog to see what may be go wrong.

    First the logs claimed about missing de-DE resources of regasm and mscorlib,

    so they installed the german language pack of 4.0.

    Our assembly uses 4.0 client package.

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client]
    "Version"="4.0.30319"
    "TargetVersion"="4.0.0"
    "Install"=dword:00000001
    "MSI"=dword:00000001
    "Servicing"=dword:00000000
    "InstallPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client\1031]
    "Version"="4.0.30319"
    "TargetVersion"="4.0.0"
    "Install"=dword:00000001
    "Servicing"=dword:00000000
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client\1033]
    "Version"="4.0.30319"
    "TargetVersion"="4.0.0"
    "Install"=dword:00000001
    "Servicing"=dword:00000000
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full]
    "Version"="4.0.30319"
    "TargetVersion"="4.0.0"
    "Install"=dword:00000001
    "MSI"=dword:00000001
    "Servicing"=dword:00000000
    "InstallPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\1031]
    "Version"="4.0.30319"
    "TargetVersion"="4.0.0"
    "Install"=dword:00000001
    "Servicing"=dword:00000000
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\1033]
    "Version"="4.0.30319"
    "TargetVersion"="4.0.0"
    "Install"=dword:00000001
    "Servicing"=dword:00000000

    regasm.exe.config

    <?xml version ="1.0"?>
    <configuration>
        <startup useLegacyV2RuntimeActivationPolicy="true">
            <requiredRuntime safemode="true" imageVersion="v4.0.30319" version="v4.0.30319"/>
            <supportedRuntime version="v4.0" sku="client" />
        </startup>
    </configuration>

    but it looks like there a still problem with .net resources.

    Under Defautl\regasm.exe there's

    mscorlib.resources, Version=4.0.0.0, Culture=de-DE, PublicKeyToken=b77a5c561934e089.htm

    with content (in german)

    *** Protokolleintrag für Assembly-Binder  (18.02.2013 @ 13:45:08) ***
    
    Fehler bei diesem Vorgang.
    Ergebnis der Bindung: hr = 0x80131040. Keine Beschreibung vorhanden.
    
    Der Assemblymanager wurde geladen aus:  C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Als EXE-Datei ausgeführt.  C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe
    --- Ein detailliertes Fehlerprotokoll folgt. 
    
    === Zustandsinformationen vor Bindung ===
    LOG: Benutzer = FRANKFUR\sld676
    LOG: DisplayName = mscorlib.resources, Version=4.0.0.0, Culture=de-DE, PublicKeyToken=b77a5c561934e089
     (Fully-specified)
    LOG: Appbase = file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/
    LOG: Ursprünglicher PrivatePath = NULL
    LOG: DynamicBase = NULL
    LOG: CacheBase = NULL
    LOG: AppName = RegAsm.exe
    Aufruf von Assembly : (Unknown).
    ===
    LOG: Diese Bindung startet im default-Load-Kontext.
    LOG: Die Anwendungskonfigurationsdatei wird verwendet: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe.Config
    LOG: Die Hostkonfigurationsdatei wird verwendet: 
    LOG: Die Computerkonfigurationsdatei von C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config wird verwendet.
    LOG: Verweis nach der Richtlinie: mscorlib.resources, Version=4.0.0.0, Culture=de-DE, PublicKeyToken=b77a5c561934e089
    LOG: Die Suche im GAC war nicht erfolgreich.
    LOG: Download von neuem URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/de-DE/mscorlib.resources.DLL.
    LOG: Der Assembly-Download wurde durchgeführt. Datei-Setup wird begonnen: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\de-DE\mscorlib.resources.dll.
    LOG: Die von der Quelle ausgeführte Setup-Phase beginnt.
    LOG: Der Assemblyname ist: mscorlib.resources, Version=4.0.0.0, Culture=de, PublicKeyToken=b77a5c561934e089.
    WRN: Der Vergleich des Assemblynamens führte zum Konflikt. CULTURE
    ERR: Der Assemblyverweis entsprach nicht der gefundenen Assemblydefinition.
    ERR: Das Setup der Assembly konnte nicht abgeschlossen werden (hr = 0x80131040). Die Suche wurde beendet.
    

    Translated in english this looks like

    *** Assembly Binder Log Entry  (18.02.2013 @ 13:45:08) ***
    
    The operation failed.
    Bind result: hr = 0x80131040. No description available.
    
    Assembly manager loaded from:  C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable  C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: user = FRANKFUR\sld676
    LOG: DisplayName = mscorlib.resources, Version=4.0.0.0, Culture=de-DE, PublicKeyToken=b77a5c561934e089
     (Fully-specified)
    LOG: Appbase = file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/
    LOG: Initial  PrivatePath = NULL
    LOG: DynamicBase = NULL
    LOG: CacheBase = NULL
    LOG: AppName = RegAsm.exe
    Calling assembly : (Unknown).
    ===
    LOG: The binding is started in default-Load-context.
    LOG: The application configuration file is used : C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe.Config
    LOG: Host configuration file is used: 
    LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG: Reference after policy: mscorlib.resources, Version=4.0.0.0, Culture=de-DE, PublicKeyToken=b77a5c561934e089
    LOG: Cache Lookup in GAC was unsuccessful.
    LOG: Attempting download of new URL :///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/de-DE/mscorlib.resources.DLL.
    LOG: Assembly download was successful. Attempting setup of file: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\de-DE\mscorlib.resources.dll.
    LOG: Entering run-from-source setup phase.
    LOG: The assemblyname is: mscorlib.resources, Version=4.0.0.0, Culture=de, PublicKeyToken=b77a5c561934e089.
    WRN: Comparing the assembly name resulted in the mismatch. CULTURE
    ERR: The assembly reference did not match the assembly definition found.
    ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
    

    The same for regasm.resources.

    - What's wrong with these .Net resources ?

    - Is there a way to force that regasm.exe uses en-us resources ?

      (So that the logs will be in english)

    Sorry for the long posting and tia.

      Hendrik

     

    Tuesday, February 19, 2013 1:50 PM
  • Hi Hendrik,

    >>- Is there a way to force that regasm.exe uses en-us resources ?

    I am afraid there is no such way.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, February 21, 2013 9:13 AM
  • So,

    it remains the first question:

    What's wrong with these .Net resources ?

    Monday, February 25, 2013 3:42 PM
  • There is an assembly mismatch on culture. When an assembly has a dependency on another assembly, the requirement is that the entire "assembbly name" matches, and that includes name, assembly version, culture, strong name. They all need to match.

    Phil Wilson

    Monday, February 25, 2013 6:49 PM