Wir haben die folgenden Punkte untersucht und suchen nach neuen Ideen oder Angriffswinkeln.Probleme mit COM Interop und .NET 3.5 - verschiedene Verhaltensweisen im Debug- und Release-Modus
Erstes Szenario:
Wir haben eine ASP.NET Web-Anwendung - .NET 3.5, C#, gebaut Targeting x86 - läuft auf IIS7/Windows Server 2008 R2 (64-Bit). Die ASP.NET-Webanwendung wird unter dem Standardanwendungspool mit aktivierten 32-Bit-Anwendungen ausgeführt.
Diese Webanwendung nutzt einige ältere Komponenten, die in VB6 geschrieben und als ActiveX-DLLs erstellt wurden. Die DLLs werden mit Regsvr32 registriert. Verweise auf diese Komponenten werden dem Webanwendungsprojekt (Visual Studio 2008) hinzugefügt, und wir verwenden die generierten Interop-Klassen.
Wenn die Webanwendung im Freigabemodus erstellt wird, werden bei jedem Aufruf einer älteren VB6-Komponente Fehler durch den alten Code ziemlich tief im Unterprogrammstapel ausgelöst. Es ist in der Regel so etwas wie:
ERROR 91 Objektvariable oder With-Blockvariable nicht gesetzt [Component: ClassName.cls: Method]
Wenn der gleiche Web-Anwendungs-Code statt in Debug-Modus eingebaut ist, die gleichen Fehler auftreten, aber sie sind intermittierend. Wenn dieselbe Aktion in der Webanwendung 10 Mal wiederholt wird (gleiche Eingaben, alles andere ist gleich), sehen wir das Problem ungefähr einmal.
Zweites Szenario:
Neben der Web-Anwendung, haben wir eine .NET 3.5 C# gebaut Anwendung x86-Targeting, die auf Windows Server 2008 R2 als Windows-Dienst ausgeführt wird (64 Bit). Dieser Dienst ruft Aufrufe an eine ActiveX-EXE ab, die sich auf die von der Website verwendeten DLLs bezieht (gemeinsames Erbe und Abhängigkeiten). Das ActiveX-EXE wird mit dem Schalter/regserver und einem zum .NET-Projekt hinzugefügten Verweis registriert. Die generierten Interop-Klassen werden verwendet. Wie bei ActiveX-EXEs werden Methodenaufrufe asynchron in ihrem eigenen Thread ausgeführt und verwenden Ereignisse, um den Aufrufer über die Beendigung zu informieren.
Wenn die .NET-Anwendung im Freigabemodus erstellt wird, rufen Methodenaufrufe an die EXE keine Fehler auf (soweit ich das sehen kann), aber das Ereignis, das im ActiveX-EXE ausgelöst werden sollte, wird nicht angezeigt von der .NET-Anwendung.
Wenn derselbe .NET-Anwendungscode im Debugmodus erstellt wird, wird das Ereignis von der EXE ausgelöst und von der .NET-Anwendung empfangen/verarbeitet.
Ich habe diese Probleme zusammen, weil sie beide mit Debug gegenüber Build-Version ändern und meine Ahnung ist, dass die Ursachen verwandt sind. Derzeit konzentrieren wir uns auf mögliche Probleme mit der Garbage Collection und der Out-of-Process-Arbeit, die von ActiveX EXE ausgeführt wird, und Threading-Problemen in der Webanwendung. Irgendwelche Ideen über Bereiche, die wir untersuchen sollten, wären willkommen.
Ich bin mir nicht sicher, ob Sie immer noch mit diesem zu kämpfen haben oder nicht, aber wenn Sie hier sind, etwas zu versuchen. Auf dieser Seite: http://www.hanselman.com/blog/PermaLink.aspx?guid=a40c0d4f-66d0-4704-94f6-0efda4a44465 wird erläutert, wie Sie die Attribute der Debug- und Release-Build-Prozesse ändern können. Versuchen Sie, das Release dem debug ähnlich zu machen und sehen Sie, ob es funktioniert, wenn Sie die Änderungen einzeln nacheinander durchführen. –