none
Je n'arrive pas à appeler ma DLL (développée en VB .NET / Framework 4) à partir d'Excel 2007 en dehors de mon poste de travail RRS feed

  • Question

  • Malgré de nombreuses recherches sur internet, je n'arrive toujours pas à appeler ma DLL développée en VB .NET à partir d'Excel sur un poste de travail sans Visual Studio 2010 et sans environnement de développement.

    Sur mon poste de travail, j'arrive sans aucun problème à appeler ma DLL à partir d'Excel 2007 (normal puisque je l'ai développée sur mon poste) mais lorsque je copie ma DLL sur un poste de travail d'un client, cela ne fonctionne pas. J'ai bon suivre tous les conseils trouvé dans les forum, je n'y arrive pas à partir d'un poste autre que le miens sans devoir installer "Microsoft Visual Studio 2010"...

    Ma classe est bien déclarée en "public", mes fonctions sont bien en "public" également.

    Voici ce que je fais sur le poste de travail du client:

    1. Je copie la DLL générée sur mon poste de travail sur le poste de travail du client. OK

    2. J'appel "RegAsm.exe" sur le poste de travail du client ("C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe") afin de définir le ".TLB" sur son système ainsi que les définitions de la Registry. OK

    3. Dans le module Visual Basic d'Excel, j'ouvre mon fichier "XLA" avec le code appelant (bien définit dans les compléments d'Excel), je vérifie si la référence (menu "outil" -> "Références...") vers ma DLL est correcte et elle l'est bien. OK

    4. J'ai ma DLL "theLibraryName" et une classe publique "clsFn" que je déclare dans le VBA d'Excel 2007 comme ceci: "Dim fn As New theLibraryName.clsFn".

    5. J'utilise les paramètres et les fonction de cette classe avec "With fn" mais si j'essaie d'aller en pas à pas dans mon code, je vois qu'il n'a pas pu définir "fn", j'ai déjà une erreur à la déclaration!

    Je ne m'explique pas pourquoi puisque Excel a bien eu sa définition dans "Outils" -> "Références..." boite de dialogue "Références - VBAProject" et la librairie est bien cochée et a le bon chemin d'accès (la "DLL" et le "TLB" s'y retrouve bien).

    Je précise aussi que la DLL a été compilée avec l'option "Register for COM interop" comme conseillé dans certain forum.

    Je ne sais plus quoi faire pour faire tourner mes fonctionnalités chez mon client.

    Pouvez-vous m'aider svp?

    Je vous remercie d'avance. Vincent



    • Modifié VRixhon jeudi 13 mars 2014 15:06 correction
    jeudi 13 mars 2014 14:59

Réponses

  • J'ai enfin réussi à faire tourner ma DLL sur le poste de travail du client!

    La solution est simple: ne pas oublier de spécifier l'option "/codebase" dans la commande "regasm" lors du déploiement.

    => C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /codebase "C:\EasyActLibrary\EasyActLibrary.dll" /tlb:"C:\EasyActLibrary\EasyActLibrary.tlb" est la bonne syntaxe.

    Encore merci pour votre aide et bonne fin de journée. Vincent


    • Marqué comme réponse VRixhon mardi 18 mars 2014 14:40
    • Modifié VRixhon mardi 18 mars 2014 14:41 correction
    mardi 18 mars 2014 14:40

Toutes les réponses

  • Bonjour

    Il n'y a pas une différence 32/64 bits?

    Quelle architecture ciblez-vous avec le DLL ?

    Quel est le message d'erreur?

    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.

    vendredi 14 mars 2014 10:39
  • Bonjour et merci pour votre réponse,

    Point de vue architecture OS, il n'y a aucune différence entre le poste de travail de développement et le poste de travail du client: Microsoft Windows 7: 32 bits.

    Il n'y a malheureusement pas de message d'erreur clair.

    Dans la cellule d'Excel, j'obtiens "#VALUE!" parce que Excel ne trouve apparemment pas ma DLL alors que tout est bien définit.

    Lorsque je fais du pas à pas (debug) dans le VBA d'Excel, tout s'arrête sur la ligne "With fn":

    Dim fn As New theLibraryName.clsFn

    -->With fn

       .variable = valeur1

       ...

       Resultat = .FUNCTION()

    end With

    Et pourtant Excel a bien eu la définition de la DLL puisque dans "Outils" -> "Références..." dans la boite de dialogue "Références - VBAProject", la librairie est bien cochée et le chemin d'accès est tout à fait correcte.Mais cela fonctionne si le client a installé "Microsoft Visual Studio 2010" sur leurs poste de travail. C'est un client particulier avec un poste prévu pour du développement. Mais nous ne pouvons pas le faire sur tous les postes des clients.

    Merci d'avance pour votre aide.

    lundi 17 mars 2014 08:53
  • Bonjour

    Le plus probable votre DLL utilise des autres DLL.

    Veuillez utiliser  Dependency Walker http://www.dependencywalker.com/  pour trouver exactement de quel DLL vous avez besoin.

    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.

    lundi 17 mars 2014 09:13
  • Bonjour,

    Merci pour votre aide.

    J'ai regardé sur le poste de travail du client avec l'application "Dependency Walker" et le programme a mis 3 DLL en rouge: "IESHIMS.DLL", "IEFRAME.DLL" et "SHLWAPI.DLL".

    Lorsque je recopie ces 3 DLL aux côté de ma DLL développée avec "VB .NET", j'ai plus de DLL en rouge: "IERTUTIL.DLL", "MSHTML.DLL", "URLMON.DLL" et "WININET.DLL". Lorsque je les recopies à nouveau su le poste de travail du client aux côté des autres DLL, rien ne change au niveau de "Dependency Walker", le mêmes DLL sont toujours marquée rouge et cela ne change rien à mon problème dans le script.

    Dois-je effectuer une opération d'enregistrement de ces DLL en plus (Registry, ... ?) ???

    Le plus curieux est que je retrouve toutes ces DLL "manquantes" dans des mises à jours de Windows 7, dans les répertoires de "C:\Windows\winsxs\x86_microsoft-windows..." (???) et nulle part ailleurs!

    De plus, ces DLL ont plutôt un rapport avec "IE" plutôt qu'avec "VB .NET"...

    J'ai également essayé en copiant les DLL en référence dans mon projet de DLL ("Interop.MSScriptControl.dll", "Interop.Scripting.dll", ...) mais cela ne change rien non plus sur le poste de travail du client.

    Auriez-vous une idée?

    Merci d'avance pour votre aide.

    lundi 17 mars 2014 14:00
  • Les trois sont des fichiers qui viennent avec IE.  Je dirais que le problème n'est pas ici.

    Question bête : vous avez .Net Framework  4.0 bien installe sur les autres ordinateurs ?

    Voir aussi  la section "Possible Problem with these Examples"  dans cet article.

    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.


    lundi 17 mars 2014 14:36
  • Sur le poste de travail du client je retrouve le répertoire "C:\Windows\Microsoft.NET\Framework\v4.0.30319\" qui devrait bien correspondre au .NET Framework 4.0 je pense.

    lundi 17 mars 2014 15:06
  • Essayez la solution proposée dans l'article ci-dessus.
    Quel est le message d'erreur complet ?

    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.

    lundi 17 mars 2014 15:22
  • Bonjour,

    Cela ne fonctionne toujours pas.

    Voici ce que j'ai fait:

    J'ai créé le fichier "excel.exe.config" dans le répertoire "C:\Program Files\Microsoft Office\Office12\" où se trouve "EXCEL.EXE" avec le contenu: 

    <?xml version="1.0"?>
    <configuration>
      <startup>
        <supportedRuntime version="v4.0.30319"/>
      </startup>
    </configuration>

    Dans la cellule Excel de l'appel vers ma fonction j'ai "#VALUE!" mais pas de message d'erreur à part ceci: "Le type de donnée d'une valeur utilisée dans la formule est incorrect.".

    Cela ne correspond pas puisque le même appel fonctionne sur mon poste de travail et sur les postes de travail où "Microsoft Visual Studio 2010" est installé.

    Auriez-vous d'autres idées?

    Merci d'avance.

    mardi 18 mars 2014 08:25
  • Executez regAsm sur les autres ordinateurs :

    c:\Windows\Microsoft.NET\Framework\version_.net\regasm.exe   MyAssembly.dll  

    Voir ce thread : http://social.msdn.microsoft.com/Forums/vstudio/en-US/fc008bcc-986a-429e-9e1b-06fc1a7f2d5b/calling-net-dll-from-vba

    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.

    mardi 18 mars 2014 08:44
  • Cela ne fonctionne toujours pas malgré cette commande.

    Voici la commande que j'ai exécuté et son résultat (où "EasyActLibrary.dll" est "theLibraryName.dll") :

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe "C:\EasyActLibrary\EasyActLibrary.dll"

    Microsoft (R) .NET Framework Assembly Registration Utility version 4.0.30319.18408
    pour Microsoft .NET Framework version 4.0.30319.18408
    Copyright (C) Microsoft Corporation 1998-2004. Tous droits réservés.

    Inscription des types réussie

    Cela ne change rien.

    J'ai également déjà essayé avec la commande suivante:

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe "C:\EasyActLibrary\EasyActLibrary.dll" /tlb:"C:\EasyActLibrary\EasyActLibrary.tlb"

    mais c'est le même résultat.

    Auriez-vous d'autres idées?

    Merci d'avance.




    • Modifié VRixhon mardi 18 mars 2014 14:42
    mardi 18 mars 2014 10:25
  • J'ai également suivi scrupuleusement toutes les instructions de l'article "A Beginner's Guide To Calling A .NET Library From Excel" (http://richnewman.wordpress.com/2007/04/15/a-beginner%E2%80%99s-guide-to-calling-a-net-library-from-excel/) et essayé sur mon poste de travail: cela fonctionne bien comme expliqué.

    Ensuite, j'ai voulu l'essayer sur le poste de travail du client. J'ai recopié la DLL sur son poste de travail, j'ai exécuté la commande pour enregistrer la DLL avec "RegAsm.exe" (pour définir le fichier ".TLB" qui a bien été généré), vérifié la librairie dans "Outils" -> "Références", ...

    Et lors de l'exécution avec "F5" dans le code (comme expliqué dans l'article), j'ai une erreur:

    "Erreur d'exécution '-2147024894 (80070002)': Erreur Automation. Le fichier spécifié est introuvable."

    Quel fichier est introuvable? Le seul serait la DLL mais elle est bien renseignée dans "Outils" -> "Références"...

    Je ne sais pas si c'est le même problème qu'avec ma librairie mais pouvez-vous m'aider svp?

    Merci d'avance.

    mardi 18 mars 2014 13:46
  • Voir la solution marquée dans ce thread :

    http://social.msdn.microsoft.com/Forums/en-US/65dc0c4a-a426-41a0-9e80-c7de37b10c73/net-and-vba-excel-interop-issue-2147024894-80070002-automation-error?forum=clr

    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.

    mardi 18 mars 2014 14:03
  • J'ai enfin réussi à faire tourner ma DLL sur le poste de travail du client!

    La solution est simple: ne pas oublier de spécifier l'option "/codebase" dans la commande "regasm" lors du déploiement.

    => C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /codebase "C:\EasyActLibrary\EasyActLibrary.dll" /tlb:"C:\EasyActLibrary\EasyActLibrary.tlb" est la bonne syntaxe.

    Encore merci pour votre aide et bonne fin de journée. Vincent


    • Marqué comme réponse VRixhon mardi 18 mars 2014 14:40
    • Modifié VRixhon mardi 18 mars 2014 14:41 correction
    mardi 18 mars 2014 14:40