none
TLBIMP génère des int à la place des long RRS feed

  • Question

  • Bonjour,

    Voici mon problème :

    les types long de ma tlb se transforme en int dans ma dll une fois l'import fait avec la commande tlbimp.exe de l'invite de commande VS2010 64bits

    Je compile ma tlb en 64bits sur un poste vista64 bits.

    Je génère mon fichier dll avec tlbimp en ajoutant l'argument /machine:x64

    Y aurait-il des références à system32 par défaut ? si oui comment les changer ?

    Cordialement,


    • Modifié Manu911 mercredi 15 janvier 2014 15:01
    mercredi 15 janvier 2014 15:00

Réponses

  • Qu'entendez-vous par  "Je compile ma tlb en 64bits sur un poste vista64 bits.", pour moi, une TLB est une bibliothèque de type et d'interfaces COM, correspondant un à ou plusieurs composants COM les implémentants.

    >Y aurait-il des références à system32 par défaut ? si oui comment les changer ?

    Non, rien à voir avec la choucroute

    Sauf erreur de ma part, mon expérience de ces manipulations n'est que théorique :

    >Je génère mon fichier dll avec tlbimp en ajoutant l'argument /machine:x64

    Vous ne faite que générer un assembly .NET qui déclare les informations sur les types et les interfaces COM contenu dans la TLB au format compréhensible par le framework .NET.

    L'option machine ne fait que rendre l'assembly généré plus optimal pour une architecture matérielle, mais je ne vois pas pourquoi le limité aux machines x64 dans un premier temps.

    >les types long de ma tlb se transforme en int dans ma dll une fois l'import fait avec la commande tlbimp.exe de l'invite de commande VS2010 64bits

    http://msdn.microsoft.com/en-us/library/windows/desktop/aa367090(v=vs.85).aspx

    le "long" COM est identique au des Int32 .NET.

    "int dans ma dll ", c'est très très vague, car une Dll non Assembly .NET n'a pas de typage "int" intrinsèque (c'est fonction de l'outil qui interprète le mangling des noms des exports de la dll) et un type int dans un assembly .NET est de longueur variable en fonction du framework qui charge l'assembly, et pas de celui de l'OS.

    C'est donc très peu probable que cela soit un "vrai" int .NET qui soit exporté par un outil comme Tlbimp. C'est vraisemblablement un raccourci fait par votre outil de visualisation.

    Pouvez-vous utilisez des outils plus bas niveau pour vos vérifications de type ? (ILDASM, OLE/COM Viewer ...)


    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse Manu911 mercredi 22 janvier 2014 15:23
    mercredi 15 janvier 2014 18:32
    Modérateur

Toutes les réponses

  • Qu'entendez-vous par  "Je compile ma tlb en 64bits sur un poste vista64 bits.", pour moi, une TLB est une bibliothèque de type et d'interfaces COM, correspondant un à ou plusieurs composants COM les implémentants.

    >Y aurait-il des références à system32 par défaut ? si oui comment les changer ?

    Non, rien à voir avec la choucroute

    Sauf erreur de ma part, mon expérience de ces manipulations n'est que théorique :

    >Je génère mon fichier dll avec tlbimp en ajoutant l'argument /machine:x64

    Vous ne faite que générer un assembly .NET qui déclare les informations sur les types et les interfaces COM contenu dans la TLB au format compréhensible par le framework .NET.

    L'option machine ne fait que rendre l'assembly généré plus optimal pour une architecture matérielle, mais je ne vois pas pourquoi le limité aux machines x64 dans un premier temps.

    >les types long de ma tlb se transforme en int dans ma dll une fois l'import fait avec la commande tlbimp.exe de l'invite de commande VS2010 64bits

    http://msdn.microsoft.com/en-us/library/windows/desktop/aa367090(v=vs.85).aspx

    le "long" COM est identique au des Int32 .NET.

    "int dans ma dll ", c'est très très vague, car une Dll non Assembly .NET n'a pas de typage "int" intrinsèque (c'est fonction de l'outil qui interprète le mangling des noms des exports de la dll) et un type int dans un assembly .NET est de longueur variable en fonction du framework qui charge l'assembly, et pas de celui de l'OS.

    C'est donc très peu probable que cela soit un "vrai" int .NET qui soit exporté par un outil comme Tlbimp. C'est vraisemblablement un raccourci fait par votre outil de visualisation.

    Pouvez-vous utilisez des outils plus bas niveau pour vos vérifications de type ? (ILDASM, OLE/COM Viewer ...)


    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse Manu911 mercredi 22 janvier 2014 15:23
    mercredi 15 janvier 2014 18:32
    Modérateur
  • Bonjour

    Manu911, avez-vous des nouvelles pour nous?

    Merci!

    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 21 janvier 2014 12:31
  • Bonjour,

    Merci pour ces précisions.

    Vous dites:

    "Qu'entendez-vous par  "Je compile ma tlb en 64bits sur un poste vista64 bits.", pour moi, une TLB est une bibliothèque de type et d'interfaces COM, correspondant un à ou plusieurs composants COM les implémentants."

    Ma tlb est obtenu en compilant un fichier dbx (fichier obtenu grace au SDK Objectarx pour AutoCAD). Je compile le projet en 64 bits.

    Vous dites :

    "le "long" COM est identique au des Int32 .NET.",

    Je vais essayer avec le type int64 comme indiqué dans votre lien mais il semblait avoir des problèmes de compilation du code en changeant le type (inmpossible d'instantier une classe abstraite ...)

    Sinon on me conseil une autre solution, référencer mon fichier dbx (objet de l'api d'AutoCAD) : c'est ce dbx qui me génère mon fichier .tlb qui lui même sert à générer mon fichier dll.

    Apparement je pourrais inscrire mon dbx en tant qu'objet COM via l'application AutoCAD, ensuite référencé cet objet com dans un projet .net qui lors de la compilation me fournirait mon fichier dll.

    Merci en tout cas de votre impliquation.

    Cordialement,


    • Modifié Manu911 mardi 21 janvier 2014 13:56
    mardi 21 janvier 2014 13:44
  • >Dans ce cas y a t-il un autre type qui puisse correspondre à un long .NEt ou un int64 ?

    Comme indiqué dans la page donné en référence dans mon précédant post :hyper ou __int64

    Si un dbx est une Dll déguisée contenant des composant COM, cette nouvelle approche me semble tout à fait viable, si votre intention est de vous en servir dans du code .NET.

    Mais avec cette approche, il n'y a pas de génération de Dll Tlb car cela est inutile.


    Paul Bacelar, Ex - MVP VC++

    mardi 21 janvier 2014 14:40
    Modérateur
  • Oui, je vous confirme que le passage en __int64 règle bien mon problème.

    Merci.

    mercredi 22 janvier 2014 15:24