none
Load Native DLL in WCF RRS feed

  • Question

  • Bonjour,

    J'ai une application Silverlight avec un WCF déployée sur un IIS 7.5 (Windows Server 2008R2)

    dans le WCF je charge une DLL (C++/CLI) avec la méthode

    static class NativeMethods { [DllImport("kernel32.dll", SetLastError = true)] public static extern IntPtr LoadLibrary(string dllToLoad); [DllImport("kernel32.dll", SetLastError = true)] public static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName); [DllImport("kernel32.dll", SetLastError = true)] public static extern bool FreeLibrary(IntPtr hModule); } public class programm { [UnmanagedFunctionPointer(CallingConvention.Cdecl)] private delegate int PilSVACallerConnect(int i, string s1, string s2); public bool Connect(// params//) {

    try{ PtrPilSVA = NativeMethods.LoadLibrary(pPath); if (PtrPilSVA == IntPtr.Zero) throw new Win32Exception(Marshal.GetLastWin32Error(), pPath); IntPtr ptrConnect = NativeMethods.GetProcAddress(PtrPilSVA, "DLP_ECHGSV_CMIO"); if (ptrConnect == IntPtr.Zero) return false; PilSVACallerConnect Connect = (PilSVACallerConnect)Marshal.GetDelegateForFunctionPointer(ptrConnect, typeof(PilSVACallerConnect)); l_Return = ((int)Connect(99, Message, BufferEchange) != 0) ? false : true;

    }}catch (Win32Exception ex32)
                {
                    Journal("Win32Exception.ErrorCode", (((Win32Exception)(ex32)).ErrorCode).ToString());
                } return l_Return; } }

    Jusqu'à là ça marche (j'ai déjà installé des clients qui fonctionne correctement).

    Je viens d'installé un nouveau client (Windows Server 2008R2 Standard Edition) et j'ai une erreur du charger de la DLL C++/Cli. le pointeur "PtrPilSVA" du Load est '0' et un erreur n° -2147467259

    Si quelqu'un  a une idée, moi je ne trouve pas.



    Cordialement


    • Modifié IghzerA mardi 4 mars 2014 13:59
    mardi 4 mars 2014 09:19

Réponses

  • j'ai opté pour la méthode classique de chargement de la DLL

    [DllImport(@"C:\inetpub\wwwroot\nomclient\wcf\bin\PILSVA\PilSVA.dll", EntryPoint = "DLP_ECHGSV_CMIO", ExactSpelling = false)]
    public static extern IntPtr DLP_ECHGSV_CMIO([MarshalAs(UnmanagedType.U4)] int i, [MarshalAs(UnmanagedType.LPStr)] string s1, [MarshalAs(UnmanagedType.LPStr)] string s2);

    et cela fonctionne correctement.

    Je pense que la méthode "LoadLibrary" par "kernel32" ne fonctionne pas chez ce client parce qu'il manque un composant Windows sur le système, mais lequel?? en tout cas c'est la seule raison qui me viens à l'esprit.

    Si quelqu'un à une idée je suis preneur.

    Merci.



    Cordialement

    • Marqué comme réponse Aurel Bera jeudi 6 mars 2014 07:26
    mercredi 5 mars 2014 17:02

Toutes les réponses

  • Bonjour,

    Cela indique que la DLL que vous essayez de charger n'existe pas. Vérifiez qu'elle se trouve dans le répertoire courant ou dans le répertoire System32.

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    mardi 4 mars 2014 22:34
    Modérateur
  • Bonjour,

    Oui, j'avais compris que le programme ne trouve pas la DLL, c'est cela qui m'est incompréhensible. De plus l'application fonctionne très bien dans mon environnement de développement.

    La DLL en question fait partie de mon package de déploiement (C:\inetpub\wwwroot\nomclient\wcf\bin\PILSVA\PilSVA.dll) le chemin est seter par variable d'environnement applicative au premier appel du Web Service.

    System.Environment.SetEnvironmentVariable("PATH_PILSVA", l_PathPILSVA, EnvironmentVariableTarget.Process);


    Cordialement

    mercredi 5 mars 2014 08:11
  • j'ai opté pour la méthode classique de chargement de la DLL

    [DllImport(@"C:\inetpub\wwwroot\nomclient\wcf\bin\PILSVA\PilSVA.dll", EntryPoint = "DLP_ECHGSV_CMIO", ExactSpelling = false)]
    public static extern IntPtr DLP_ECHGSV_CMIO([MarshalAs(UnmanagedType.U4)] int i, [MarshalAs(UnmanagedType.LPStr)] string s1, [MarshalAs(UnmanagedType.LPStr)] string s2);

    et cela fonctionne correctement.

    Je pense que la méthode "LoadLibrary" par "kernel32" ne fonctionne pas chez ce client parce qu'il manque un composant Windows sur le système, mais lequel?? en tout cas c'est la seule raison qui me viens à l'esprit.

    Si quelqu'un à une idée je suis preneur.

    Merci.



    Cordialement

    • Marqué comme réponse Aurel Bera jeudi 6 mars 2014 07:26
    mercredi 5 mars 2014 17:02
  • Merci de votre retour.

    Cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 6 mars 2014 07:26
  • Bonjour,

    J'ai eu quasiment la même que vous hier matin.
    J'avais un assembly .NET d'un éditeurs tiers qui faisait appel une DLL native qui faisait appel à d'autres DLL natives. Il en manquait une DLL sur un serveur en production.

    Pour détecter la DLL native manquante, j'ai utilisé l'utilitaire Dependency Walker : http://www.dependencywalker.com/

    ATTENTION : Si vos DLL native sont en 64-bit il faut utiliser la version 64-bit de Dependency Walker, si vos DLL native sont en 32-bit il faut utiliser la version 32-bit.

    Sur un autre serveur il y avait la propriété PATH (utilisé par Windows pour rechercher les DLL natives) qui était mal renseigné.

    En espérant que cela puisse vous aider...

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    mardi 11 mars 2014 09:02
    Modérateur
  • Bonjour,

    j'avais déjà vérifié avec dependency walker et j'avais rien trouvé.

    mais je crois que c'est service pack qui n'est pas installé, je n'ai pas fais de test mais il est fort probable que c'est cause.


    Cordialement

    vendredi 14 mars 2014 15:57