COM inscription échoue: “l'Automatisation d'erreur: le système ne peut pas trouver le fichier spécifié”, lors de l'installation de la dll dans un autre dossier que le fichier tlb
Nous avons un composant COM (appelons-la "MyLib) développé dans VB.NET pour notre application d'Accès (appelons-la" MyApp) à utiliser. Pour ce faire, nous avons besoin de faire COM inscription à l'aide de l'généré MyLib.dll et MyLib.fichiers tlb. Lorsque j'installe les fichiers dans notre MyApp du dossier, tout fonctionne bien, la COM, la fonction est appelée correctement. Cependant, j'ai une erreur mentionnée dans le titre, lorsque je suis à l'installation de la dll dans un dossier commun - la raison pour laquelle je suis en train de faire, c'est parce que nous voulons permettre à des versions différentes de MyApp à être installé sur la même machine. Donc, si le composant COM ne change pas, bien sûr nous voulons la partager entre ces différentes versions et laisser Windows faire le compte de référence.
Je ne suis pas sûr de l'endroit où je devrais mettre le MyLib.fichier tlb, soit dans MyApp du dossier d'installation, ou le même dossier que MyLib.dll. Mais de toute façon, j'ai essayé les deux endroits, et ils ont tous fait la même erreur. J'ai essayé de comparer les fichiers de registre entre le cas quand j'ai mis MyLib.* dans MyApp du dossier, et le cas quand je l'ai mis MyLib.dll dans le dossier commun. Je ne vois aucune différence à l'exception bien sûr de la base de Code de la Classe j'essaie de m'inscrire sous HKCR\Wow6432nodes\CLSID{MYCLSID}\InprocServer32. Une autre chose que je ne comprends pas c'est qu'il ne sous-clé nommée TypeLib sous HKCR\Wow6432nodes\CLSID{MYCLSID} dans les deux cas, ce qui à mon sens est le moyen de liaison de la bibliothèque de types à la dll (mais pourquoi est-il toujours de travailler quand j'ai mis tlb et la dll dans le même dossier?) depuis dans MyApp il sait seulement qu'il y a une référence de nous ajouter en référence de MyLib.tlb.
Je ne comprends pas exactement comment COM d'ouvrages de référence pour Accéder à l'application, donc si je me trompe merci de me corriger. Quelqu'un peut-il me dire ce que j'ai fait de mal? Quelle est la façon correcte de s'inscrire partagé dll COM (mettre les deux dll et tlb dans le dossier partagé ou non)? Merci!
Mise à JOUR:
Concernant l'enregistrement COM, je suis à l'aide de WIX pour créer un programme d'installation de Windows et heat.exe la récolte de l'information à partir de la dll et les fichiers tlb. Le fichier généré contient les informations de Classe, ProgID, bibliothèque de types, de Registre et de balises. Comme je l'ai mentionné, la seule différence entre mes deux cas, à partir de WIX de la configuration de point de vue, est l'endroit où je l'ai mis MyLib.dll fichier (je suppose de mettre MyLib.fichier tlb dans MyApp dossier d'installation est dans le bon sens, encore une fois, merci de corriger mes si je me trompe), et quand j'ai mis les dll et les fichiers tlb en application du dossier d'installation, il fonctionne. Voici quelques une structure de registre après l'enregistrement
Tout d'abord je dois HKCR\CLSID\{MYCLSIDs}, chacun d'eux représente l'une de mes classe COM. dans la sous-clé nommée "InprocServer32", j'ai l'Assemblée, la Classe, la base de Code, RuntimeVersion:, threadingModel. Et le Code est soit commune de dossier (pas de travail) ou MyApp du dossier d'installation(de travail), qui est l'différents endroits j'ai mis les dll. Je pensais qu'il y aurait une autre sous-clé de la bibliothèque de types de sous {MYCLSIDs}, puisque l'Accès ne voit que la bibliothèque de types et je pense qu'il doit y avoir un lien à partir de la bibliothèque de types à la dll réelle, cependant, dans les deux cas, cette sous-clé est manquante, mais dans le second cas, il est encore à travailler. Est-il un problème?
Deuxièmement, j'ai HKLM\Software\Classes\CLSID\{MYCLSIDs}, cette touche a la même structure que celle décrite ci-dessus.
Troisièmement, la HKCR\{MYPROGIDs}, ce sont juste des Progid de mes classes
Quatrièmement, HKCR\Typelib\{LibID}, qui contient les informations de fichier tlb, et cette ID de l'Assemblée GUID de projet du composant COM.
Enfin, la HKEY_CLASSES_ROOT\Interface\{InterfaceID}, il existe une sous-clés nommé ProxyStubClsid32 avec la valeur {00020424-0000-0000-C000-000000000046}, et le nom de bibliothèque de types et la valeur est mon LibID.
Il semble que la seule différence est la base de Code dans les premiers points (je peux me tromper mais c'est ce que je vois). s'il vous plaît laissez-moi savoir si vous pouvez voir n'importe quel problème. Merci!
DEUXIÈME MISE À JOUR:
Après que j'ai installé MyLib.dll dans le dossier partagé, la COM, l'appel échoue. Mais si je remplace toutes les valeurs de la base de Code SHARED_FOLDER\MyLib.dll pour INSTALLDIR\MyLib.dll et copie MyLib.dll en INSTALLDIR, il fonctionne réellement. Inversement, après que j'ai installé MyLib.dll en INSTALLDIR(dans ce cas, COM travaille), je change le Code de valeurs à partir d'INSTALLDIR\MyLib.dll pour SHARED_FOLDER\MyLib.dll et en faire une copie pour SHARED_FOLDER, cette fois, il échoue. Il semble donc que c'est exactement l'emplacement d'installation du problème, qui est à l'opposé de ma compréhension de COM. Et je ne pense pas qu'il y est un problème d'autorisation pour la SHARED_FOLDER(je peux me tromper) car il est dans un dossier de mon programme d'installation crée.
merci pour votre commentaire. Veuillez voir ma mise à jour le post original.
Great stuff maintenant vous savez pourquoi .net est tellement agréable! Comme pour votre suivi, je n'ai pas grand chose à ajouter. <<je suppose de mettre MyLib.fichier tlb dans MyApp dossier d'installation est dans le bon sens, encore une fois, merci de corriger mes si je me trompe>>. À partir d'un .net point de vue, en plaçant l' .dll dans le même .net app dossier d'aide, mais à partir d'un Accès Accdb/windows point de vue de l'emplacement du dossier n'est pas grave du tout, car ce type d'enregistrement est disponible pour tous les programmes windows en mesure de consommer l'objet com(s). Donc windows com inscription est différent .net et l'emplacement du dossier n'est pas important à l'Accès.
J'ai ajouté une deuxième mise à jour, consultez. Vous avez mentionné le l'emplacement du dossier n'est pas de faire une différence, mais j'ai obtenu le résultat inverse.
OriginalL'auteur tete | 2012-07-26
Vous devez vous connecter pour publier un commentaire.
Comment les objets com works pour windows est le même depuis que ce truc est apparu en 1990. Donc, nous parlons de la viande et des pommes de terre pilier ou de la technologie qui été autour pendant 22 ans (et c'était longtemps avant la manière dont les objets sont créés dans .net).
Alors, comment com œuvres est la même en ce qui concerne l'Accès, ou de Delphes, ou FoxPro ou VB6 ou tout système qui est en mesure de consommer un objet com.
Ensuite, il est important de garder à l'esprit que pour les objets com le registre de ces objets sur un ordinateur est de nature MONDIALE.
Il n'y a RIEN qui se rapproche de la notion de liaison dynamique des objets placés dans le même dossier que vous avez dans .net.
De sorte que le way.net oeuvres ne pas exiger un enregistrement (en fait, vous n'avez pas besoin d'inscription!).
Cependant in.net vous POUVEZ enregistrer un objet dans le global assembly si vous le souhaitez (GAC). C'est donc le choix que vous avez, mais un tel choix n'est pas un standard de windows com objet, mais que d'une .nette de l'objet. Donc those.net les objets ont ZÉRO ET RIEN à voir avec le standard de windows com objets que nous avons eu depuis 22 ans maintenant.
De sorte que la plupart des objets .net sont en fait les locaux de la dir, mais ce n'est pas un choix, pour une fenêtre standard des objets com.
Afin de convertir correctement un .net un objet ou d'un assemblage dans un utilisable et de travail windows com objet, l'objet doit GLOBAL de l'ordinateur. Ces moyens utilisez-vous pas regsvr32, mais, en fait, va utiliser le .enregistrement net outil appelé regasm (qui en effet ne faire une regsvr32 finalement pour vous après la construction d'un objet com pont pour vous). Aussi garder à l'esprit dont vous avez besoin pour compiler pour la bonne version de bit ici.
Et si vous déploiement à d'autres ordinateurs, puis définissez votre projet de production d'un objet 2.0 si vous avez une grande chance de la .net de la bibliothèque(s) ayant été installé sur l'ordinateur cible. Ainsi, lors du déploiement, vous devez utiliser regasm:
Celui-ci:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe
Le PLUS IMPORTANT est de ne PAS oublier d'ajouter le /la base de code à la ligne de commande utilisation de regasm.exe puisque vous DEVEZ le registre .net de l'objet dans le GAC (Global Assembly Cache). Si vous ne le faites pas, alors non .net applications qui prennent en charge windows com objets ne verrez pas noir être en mesure d'utiliser l'assemblée comme un standard de windows objet com.
Donc, quand on parle de non .net les objets il n'y a pas de concept de l'enregistrement ActiveX ou de ce qui est commun dénommé windows com sur l'objet d'un dossier par dossier à la base – il est toujours de nature mondiale.
En tant que tel, il est un point discutable de ce répertoire ou le dossier que vous placez l' .dll dans. Une fois que vous enregistrez correctement .dll, puis il sera disponible pour tous les systèmes qui prennent en charge les objets com.
Cela signifie également que lors du processus d'inscription .net, alors vous devez utiliser de l'assemblée mondiale de registre option (sinon cela ne fonctionnera pas).
Cette réponse donne sur Windows side-by-side (côte à côte) des capacités de déploiement qui vous permettent d'utiliser Dll COM sans inscription. Ce n'est pas pour le rendre totalement équivalent à la façon dont .NET déploiement fonctionne, mais c'était un grand pas quand il a été introduit.
OriginalL'auteur Albert D. Kallal
Il s'est avéré que MyLib.dll est l'utilisation de certaines autres bibliothèques, qui sont encore installés dans le MyApp dossier d'installation. Et donc dans ce cas que MyLib.dll est installé dans le dossier partagé, il essaie de trouver ces bibliothèques dans les mêmes bibliothèques, qui ne tient pas. Quand j'ai installer ces bibliothèques dans le dossier partagé de trop, il est de travail.
BTW j'ai trouvé fulogvw.exe très utile lors de la traque de l'assemblée problème de chargement. Par exemple dans mon cas, dans l'échec du journal qu'il dit ne peut pas charger le fichier xxx.dll dans SHARED_FOLDER, l'xxx.dll est une bibliothèque qui MyLib.dll utilise, et je n'avais aucune idée que MyLib.dll besoin jusqu'à ce que je vois le journal.
OriginalL'auteur tete