J'ai récemment développé un contrôle utilisateur interop dans .NET (Visual Studio 2008, projet ciblant .NET 2.0) à utiliser dans une application VB6. L'assemblage expose 1 contrôle, 1 classe, et quelques enum et structs. Je l'ai développé en utilisant des traductions C# du modèle de projet Interop Forms Toolkit 2.0found here. L'assemblée a un nom fort et est installé dans le GAC et inscrit regasm avec le script suivant:Compilation de l'application VB6 avec .NET interop, fonctionne uniquement si compilé sur ma machine
@"C:\gacutil.exe" /i "C:\Program Files\AppName\Control.dll" /f
@"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe" "C:\Program Files\AppName\Control.dll" /tlb:"C:\Program Files\AppName\Control.tlb"
Le problème: Quand je compile l'application VB6 sur ma machine, il fonctionnera très bien sur tout autre machine (commande installée, bien sûr). Cependant, lorsque l'application est compilée sur une autre machine, elle fonctionnera sur cette machine, mais pas sur aucune autre machine. Et quand je dis que ça ne marche pas, je veux dire que vous essayez de l'exécuter et absolument rien ne se passe.
J'ai utilisé OleView pour examiner le contrôle sur mon ordinateur et sur l'autre ordinateur, et tous les GUID sont identiques dans les informations de type. La seule différence était que l'un avait la ligne importlib ("stdole2.tlb") et l'autre avait importlib ("STDOLE2.TLB").
Mon ordinateur dispose de: Visual Studio 6.0 sp6, modèles de contrôle utilisateur interopérabilité VB6, Windows SDK 6.0 et 6.0A, Visual Studio 2008 sp1. Cette machine est celle qui fonctionne.
Machine Coworkers: Visual Studio 6.0 SP6, Visual Studio 2005
Une autre machine: Visual Studio 6.0 SP6, Visual Studio 2008. 2008 a été installé sur ce matin et ne pas régler le problème.
Comment puis-je demander à ces autres machines de compiler correctement l'application VB6 pour qu'elle fonctionne sur des machines autres que celle sur laquelle elle a été compilée?
(PUT demandes pour plus d'informations dans les commentaires et je vais modifier pour répondre.)
Edits:
Une suggestion a été faite en ce qui concerne les autorisations en ce qui concerne l'enregistrement de la commande. J'aimerais préciser que le contrôle semble bien fonctionner. Je l'enregistre de la même manière sur la machine qui fonctionne et celle qui ne fonctionne pas. Le problème se manifeste lorsque l'application VB6 qui référence le contrôle est compilée sur une machine autre que la mienne.
Je devrais également ajouter que j'avais une petite application hôte VB6 qui avait 1 formulaire et le contrôle interop et quelques boutons. Celui-ci ne présente pas le même problème que l'application principale VB6.
Peut-être un indice
Si quelqu'un est familier avec l'utilisation Oleview.exe, je pense que je l'ai découvert un indice. Lorsque je vois la liste des bibliothèques de types, il y a "OrderControl (Ver 0.1)" ainsi que "OrderControlCtl (Ver 0.1)". La première utilise le GUID défini pour l'assembly et le chemin montre le OrderControl.tlb généré à partir de RegAsm.exe. Le second a des GUID différents sur les différentes machines et le chemin sur le mien est "C: \ Program Files \ Microsoft Visual Studio \ VB98 \ vbc00305.oca", le chemin sur l'autre machine est "C: \ Program Files \ Microsoft Visual Studio \ VB98 \ mscoree.oca ", et sur la machine du collègue est" C: \ windows \ system32 \ mscoree.oca ". Les deux mscoree.oca sont de la même taille, mais le vbc00305.oca sur ma machine est plus petit de plusieurs Ko.
J'ai réexaminé les références du projet VB6.Les références listent à la fois OrderControl et OrderControlCtl, mais seulement OrderControlCtl est vérifié. L'emplacement de OrderControl est le fichier TLB, mais l'emplacement de OrderControlCtl est le fichier OCA qui est différent sur chaque station.
Dépendance Walker
J'ai couru dans DW profils pour une version du fichier EXE compilé sur ma machine et une compilation sur notre machine de construction (qui ne fonctionne pas sur le mien). Ils divergent aux 2 lignes suivantes. Tous les deux ont la première ligne, mais celui qui va se poursuit avec plus d'appels/charges, alors que celui qui ne ruisselle pas immédiatement commence à détacher après la première ligne ici:
GetProcAddress(0x7E720000 [SXS.DLL], "SxsOleAut32RedirectTypeLibrary") called from "OLEAUT32.DLL" at address 0x7712A637 and returned 0x7E746129.
GetProcAddress(0x7E720000 [SXS.DLL], "SxsOleAut32MapConfiguredClsidToReferenceClsid") called from "OLEAUT32.DLL" at address 0x7712A637 and returned 0x7E745C0D.
Est-ce que cela a à voir avec les permissions? Je veux dire - essayez de mettre le contrôle dans un répertoire, quel utilisateur a accès, l'enregistrer et voir si cela fonctionne. – shahkalpesh
@shahkalpesh: Je ne suis pas sûr de comprendre votre suggestion. Mais je sais que tout est dans Windows XP, s'exécutant en tant qu'utilisateur de niveau Administrateur. –