Ich habe eine C# -Assembly, die ich über COM aus einer Delphi (Win32 native) -Anwendung aufrufen.Warum registriert regasm.exe meine C# -Assembly mit der falschen GUID?
Dies funktioniert auf allen Maschinen, auf denen ich es getestet habe, außer einem.
Das Problem ist, dass die Delphi-Anwendung beim Versuch, das COM-Objekt zu erstellen, "Klasse nicht registriert" erhält.
Nun, wenn ich in der Registrierung unter HKEY_CLASSES_ROOT\DelphiToCSharp\CLSID
suchen, ist die GUID, die dort aufgeführt ist nicht das gleiche wie die Assembly Guid in AssemblyInfo.cs. Es sollte das gleiche sein - es ist das gleiche auf allen anderen Computern, auf denen es installiert ist.
Ich habe versucht regasm /unregister delphitocsharp.dll
, und das entfernt den Registrierungsschlüssel. Dann, wenn ich regasm delphitocsharp.dll
mache, gibt der Registrierungsschlüssel zurück, aber die GUID ist die gleiche wie zuvor (dh falsch), und Delphi bekommt immer noch "Klasse nicht registriert".
DelphiToCSharp.dll auf der Arbeitsmaschine ist mit der Version auf der nicht funktionierenden Maschine identisch (verifiziert mit MD5).
Alles was ich denken kann ist, dass eine alte Version der DLL zuvor registriert wurde, und es gibt immer noch einen Rest dieser Datei, die regasm verwirrt macht.
Wie kann ich dieses Problem beheben oder zumindest weiter diagnostizieren?
Es kann nicht im GAC sein, weil meine Assembly nicht signiert ist. Guter Punkt, ich werde nach anderen Kopien der Datei suchen. – Blorgbeard
.Net Assembly lädt nicht die DLL in so viele Verzeichnisse wie win32, so dass dies kaum der Fall sein kann. –