Laden...

[erledigt] COM Server DLL funktioniert nicht

Erstellt von tonka vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.583 Views
tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren
[erledigt] COM Server DLL funktioniert nicht

Hy@all,

ich versuche seit geraumer Zeit einen COM-Server zu erstellen (momentan In-Proc sprich DLL und später out-of-proc sprich exe) und habe auch schon einige Artikel (unter anderem bei CodeProject) gelesen. Ich hab nun ein Testprojekt aufgesetzt um das "erlernte" auszuprobieren. Mein Problem ist, das ich das COM-Object nicht instanzieren kann.

Mein kleines Testprojekt sieht folgendermaßen aus:

COMTestObject - DLL:

COMTestObject .cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;


namespace COMTestObject
{
    [Guid("DADA72CF-6040-4e7e-9E4C-28E845F09CC3")]
    [ComVisible(true)]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    public class COMTestObject : ICOMTestObject
    {

        #region ISimpleCOMObject Member

        public void Method01(string Message)
        {
            Console.WriteLine("Methode_01: " + Message);
        }

        #endregion
    }
}


ICOMTestObject.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;

namespace COMTestObject
{
    [Guid("E6C3186C-7034-4114-80AB-90FB20D1D434"), InterfaceType(ComInterfaceType.InterfaceIsDual)]
    public interface ICOMTestObject
    {
        void Method01(String Message);
    }
}

RegStart.bat //wird beim Post-Build ausgeführt!


%windir%\Microsoft.NET\Framework\v2.0.50727\regasm COMTestObject.dll /tlb /verbose
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil" /i COMTestObject.dll /f

Der Output sieht wie folgt aus

------ Neues Erstellen gestartet: Projekt: COMTestObject, Konfiguration: Debug Any CPU ------
c:\WINDOWS\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig /nowarn:1701,1702 /errorreport:prompt /warn:4 /define:DEBUG;TRACE /reference:"c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:"c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll" /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:"c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll" /debug+ /debug:full /filealign:512 /keycontainer:VS_KEY_82FDDACEF41B29A9 /optimize- /out:obj\Debug\COMTestObject.dll /target:library ICOMTestObject.cs Properties\AssemblyInfo.cs COMTestObject.cs

Kompilierung abgeschlossen -- 0 Fehler, 0 Warnungen
COMTestObject -> E:\Visual Studio 2008\Projects\COMServerTests\COMObject\bin\Debug\COMTestObject.dll
RegStart
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004. Alle Rechte vorbehalten.

Die Typen wurden registriert.
Der Typ C wurde exportiert.
Die Assembly wurde nach E:\Visual Studio 2008\Projects\COMServerTests\COMObject\bin\Debug\COMTestObject.tlb exportiert, und die Typbibliothek wurde registriert.
Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.

Die Assembly wurde dem Cache erfolgreich hinzugefügt.
========== Alles neu erstellen: 1 erfolgreich, Fehler bei 0, 0 übersprungen ==========

Interessant finde ich die Zeile "Der Typ C wurde exportiert". Durch den Parameter /verbose sollte laut Doku eigentlich alle exportierten Typen stehen. Ich würd mal schätzten das wenn nur Typ C dort steht, nichts exportiert wurder, oder?

TestApp - Die Test-Exe

Program.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
using System.Runtime.InteropServices;

namespace TestApp
{
    static class Program
    {
        [STAThread]
        static void Main()
        {
            //Type type = Type.GetTypeFromCLSID(new Guid("DADA72CF-6040-4e7e-9E4C-28E845F09CC3"));
            Type type = Type.GetTypeFromProgID("COMTestObject.COMTestObject");
            object obj = Activator.CreateInstance(type); // hier wird die Exception geworfen
        }
    }
}

Die Exception beim Instanzieren:

Die COM-Klassenfactory für die Komponente mit CLSID {DADA72CF-6040-4E7E-9E4C-28E845F09CC3} konnte aufgrund des folgenden Fehlers nicht abgerufen werden: 80040154.

Durch's googlen weiß ich das 80040154 bedeutet das die DLL nicht registriert ist, jedoch in der Registry steht alles richtig drin (Pfad usw).

Registry:

DADA72CF-6040-4E7E-9E4C-28E845F09CC3
- Implemented Categories
  - {62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}
- InprocServer32
  - 1.0.0.0
-ProId

Kennt jemand das Problem?

Rechner:
-) OS: Win XP x64 SP2
-) Visual Studio 2008 SP1
-) .NET 3.5

MfG
Tonka

B
387 Beiträge seit 2005
vor 13 Jahren

Hi,

also auf den ersten Blick fällt mir schon auf, dass bei ComTestObject die ProgID fehlt:

[ProgId("COMTestObject.COMTestObject")]

Weiß jetzt nicht, ob das notwendig ist, aber ich schreib das eigentlich immer hin.

Hast du schon mal mit dem Tool oleview geschaut, ob dein COM-Objekt auch richtig registriert ist? Das Durchblättern der Typelibrary dort zeigt oft schon, warum es nicht geht.

Gruß

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

Hallo Blacal,

die ProgID wird automatisch vergeben, sofern ich sie nicht angebe (Es kommt dann, wie du schon geschrieben hast "COMTestObject.COMTestObject" raus).

mit oleview hab ich schon angeschaut und in der typelib steht alles richtig drin.

Hab den Fehler selber schon gefunden und der ist mehr als dämlich 😉

Ich habe beim Registrieren einen Fehler gemacht. Ich arbeite unter Win XP x64. Bisheriger Code:


%windir%\Microsoft.NET\Framework\v2.0.50727\regasm COMTestObject.dll /tlb /verbose
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil" /i COMTestObject.dll /f

Der Ordner Framework stimmt für x86, aber für x64 muss dort aber **Framework64 **als Ordner angegeben werden. Das erklärt auch den Fehler, warum ich es in der Registry finden konnte (wohl gemerkt unter WOW6432Node) und beim Ausführen nicht. Ich habe es als x86 registriert und nicht als x64, somit konnte das Programm logischer weise den Eintrag nicht finden.

Habs jetzt korrigiert und jetzt funktioniert's prima.

MfG
Tonka

B
387 Beiträge seit 2005
vor 13 Jahren

Hi,

aber was mich jetzt trotzdem noch interessieren würde:
Warum registrierst du die Dll eigentlich manuell? Dafür gibt es doch einen Hacken in den Projekteinstellungen (Für COM sichtbar machen, oder so) - jedenfalls benutze ich den immer.

Gruß

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

Naja, ich habe mir sehr viel Doku's von anderen durchgelesen. Die meisten haben geschrieben, dass die Visual Studio Integration (also der Haken in den Projektoptionen) ziemlich verbugt ist und oftmals Fehler gar nicht meldet und somit sollte man besser die exe-Dateien zum registrieren nutzen. Außerdem hat man gleich die Registrationsdateien für die Clients.
Funktioniert bei dir die VS Integration problemlos?

B
387 Beiträge seit 2005
vor 13 Jahren

Läuft bei mir (Vista 32-Bit) ohne Probleme. Auch auf anderen Rechnern mit XP ist mir noch nichts zu Ohren gekommen.

Einzig bei der Setup-Erstellung funktioniert es wohl ab Windows Vista nicht mehr (Wenn man ein Standard Setup-Projekt von VisualStudio verwendet), da muss man dann das Setup entweder auf einen XP Rechner erstellen oder dann eben trotzdem manuell machen. Ich persönlich hab dafür eine Windows XP VM missbraucht.
Auf Windows 7 hab ich aber noch nicht ausprobiert.

Beim erstellten Setup hab ich auch noch keine Probleme gehabt. Registriert die Dlls auf XP, Vista und Windows 7 Rechnern (allerdings sind alle meine COM-Dlls bis jetzt nur 32-Bit gewesen).

Gruß

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

Hast du schon mal einen out-of-proc COM Server gemacht, d.h. eine exe-Datei? Ich habe nämlichen eine exe Datei, auf die ich auch über COM zugreifen muss!

MfG

B
387 Beiträge seit 2005
vor 13 Jahren

Nein, bis jetzt nur dlls.