2009-03-06 12 views
21

Bis vor kurzem waren wir glücklich mit registration-free COM für unsere nativen und .NET COM-Komponenten. Wir stießen jedoch auf ein seltsames Problem, bei dem unsere Anwendung zufällig auf Windows XP SP3 (aber nicht auf Vista) abstürzte, nachdem wir nur die Versionsnummer einer .NET Assembly geändert hatten, um von Release Candidate zu Release zu wechseln. (Sie hassen Murphys Gesetz nicht?)Wird erfolgreich registrierungsfreie COM mit .NET-Komponenten verwendet?

Nach vielen verlorenen Manntag und Zähneknirschen stellten wir fest, dass das Problem ein known bug in sxs.dll war, der Heap-Korruption beim Abrufen von Informationen über eine .NET-Klasse verursacht. Es gibt einen Hotfix, der das Problem verschwinden lässt, Hotfixes sollen jedoch nicht neu verteilt werden.

Wir sind ziemlich ratlos, dass es einen so schrecklichen Fehler in der Registrierung-freie COM-Implementierung gibt. Ist jemand erfolgreich ohne registrierungsfreie COM für .NET-Komponenten? Wie haben Sie dieses Problem gelöst?

+0

+1 wichtige Frage, die ich nicht bewusst war! BTW kann ich vorschlagen, dass Sie das Tag "regfreecom" hinzufügen, da dieses Tag häufiger für Registry-freie COM-Fragen ist? – MarkJ

+1

... tatsächlich habe ich es einfach selbst retagged ... hoffe, dass OK – MarkJ

+0

Sicher. Konsistente Tags sind nützlicher. –

Antwort

9

Dieses Problem hängt damit zusammen, wie SxS die Größe der Klasseninformationen berechnet. Die Versionsnummer der Baugruppe ist Teil dieser Information.

Da es mit der Release Candidate-Versionsnummer gearbeitet hat, besteht die Workaround für Sie darin, die Versionsnummer des Releases auf die gleiche Länge wie die RC-Version zu setzen.

Wenn dies für Sie nicht funktioniert, gibt es einen etablierten Prozess zum Anfordern von Redistributionsrechten für Hotfixes. Ich würde mich an den Microsoft-Kundensupport wenden, um diese Route zu verfolgen.

4

Wir verwenden registrierungsfreie COM für native und .NET-Komponenten. Wir haben uns entschieden, eine feste Assembly-Versionsnummer für diese Komponenten zu verwenden (hauptsächlich, um zu verhindern, dass die Registrierung überflutet wird, wenn .NET-Komponenten, die eine dynamische Build-Nummer/* hatten, wiederholt aktualisiert wurden). Nicht ideal, aber wir haben andere Möglichkeiten festzustellen, welche Version einer bestimmten Komponente verwendet wird (sie werden nie einzeln gepatcht).

Das klingt in der Tat ein sehr unangenehmes Problem! In diesem KB-Artikel scheint es fast so, als wäre die Verwendung von SxS optional ... Soweit ich weiß, ist dies der einzige Weg, um reg-free COM zu machen.

+1

Danke für die Antwort. Wenn wir von anderen hören, die reg-free COM für .NET ohne Probleme verwenden, deutet dies darauf hin, dass wir vielleicht einfach Pech gehabt haben. Beachten Sie, dass das Problem für uns wahrscheinlich eine Änderung der Größe der Assembly ausgelöst hat. Wenn Sie die Version nicht ändern, schützt Sie das wahrscheinlich nicht. –