Debuggen langsamer Office-Anwendungs-Interop-Konstruktor?

Question

Ich habe eine Anwendung, die sich mit Excel befasst. Kürzlich habe ich ein Problem mit sehr langsamen Erstellung von Excel-Objekt festgestellt.

Ich habe das Problem mit diesem einfachen Code neu:

Microsoft.Office.Interop.Excel.Application xlApp; 
xlApp = new Microsoft.Office.Interop.Excel.Application(); 

Die zweite Zeile bewirkt, dass die Verzögerung.

Um den Zeitaufwand für die Neuzuordnung von Objekten zu messen, wurde der obige Code um die Zeiterfassungslösung erweitert und die Ergebnisse sind eindeutig. In der NORMAL-Situation wird der obige Code in 0,5 Sekunden ausgeführt, während im Falle von FEHLERBEHEBUNG es bis zu 5 Minuten dauern kann.

Es gibt keine Speicherlecks und Excel-Objekte werden ordnungsgemäß freigegeben. Meine Lösung lief das ganze Jahr rund um die Uhr ohne Probleme. Ich bin mir nicht sicher, ob es wichtig ist, aber die Anwendung läuft auf 20 separaten Benutzersitzungen (Server-Maschine). Es werden also 20 Kopien dieser Anwendung gleichzeitig ausgeführt und es können 20 Kopien von Excel zur gleichen Zeit ausgeführt werden.

Zum ersten Mal wurde das Problem vor 2 Monaten bemerkt und wurde durch Upgrade von Office (2010 -> 2013) behoben. Diesmal habe ich mehr Zeit zu untersuchen und leider sind die Ergebnisse nicht vielversprechend.

Fakten:

• nur eine Maschine zur Zeit von diesem Problem betroffen (24 CPU-Kern, 24 GB Ram)
• CPU ist überhaupt nicht gestresst, wenn die "Verzögerung" geschieht
• Ich habe versucht mit "Prozessmonitor" -Anwendung zu überprüfen, was passiert, wenn wir "neue Excel.Application()" -Konstruktor (um zu sehen, ob es eine übermäßige Festplatten-/Arbeitsspeicher/CPU-Nutzung ist) - keine Anzeichen von Ressourcenbeschränkungen. Keine Zeichen von Protokolldateien, die sich auf COM-Objekte usw. beziehen.
• Das einzige Problem hier ist diese paar Minuten Verzögerung. Alle anderen Excel Interop-Befehle funktionieren wie gewohnt.

Haupt Frage:

• Gibt es eine Möglichkeit, diese Microsoft.Office.Interop.Excel.Application zu debuggen() Konstruktor, um zu sehen, welchen Teil ist hier ein Thema?

Externer Inhalt

• One guy with similar issue. His solution didn't help with my problem at all.

EDIT - weiterer Test

Powerpoint-Konstruktor wird nicht durch die Verzögerung betroffen

ppApp = new Microsoft.Office.Interop.PowerPoint.Application(); 

Answer 1

Ich habe die Lösung selbst gefunden. Ich poste es, da jemand anderes auf ein ähnliches Problem stoßen kann und es ihm Stunden/Tage der Untersuchung ersparen kann.

Was habe ich getan, um eine Lösung zu finden?

Ich habe Testanwendung analysiert (im Grunde nur eine Zeile, wo neue Excel-Anwendung erstellt wird) mit Process Monitor und es zeigte nichts Wichtiges. Dann wiederholte ich die Analyse mit neu gestartetem Excel-Prozess. Es markierte zahlreiche Lesevorgänge der Windows-Registrierung

HKEY_USERS\S-1-5-21-2929665075-1795331740-364918325-1024\Software\Microsoft\Office\15.0\Excel\Resiliency\DocumentRecovery 

Unter obigen Speicherort habe ich Zehntausende von Schlüsseln entdeckt. Sie alle wurden durch die "automatische Wiederherstellung" von Excel erstellt. Aufgrund der Nummern dauerte das Laden der Dateien beim Starten eines neuen Excel-Objekts ungefähr 40 Sekunden. Diese Nummer wurde zusätzlich mit weiteren 10-20 gleichzeitig geladenen Sitzungen multipliziert (habe ich erwähnt, dass meine Anwendung in 20 Benutzersitzungen läuft?).

Lösung: Entfernung von "Resiliency" Registrierungsstruktur tut den Trick.

Warum waren all diese "Auto-Recovery" -Einträge an erster Stelle? Ich denke, dass ich Excel nicht sehr gut schließe und es "denkt", dass ich regelmäßig abstürze und "versuche" zu helfen.

---

Jetzt, was übrig bleibt, verhindert, dass es wieder von vorne passiert. Ich werde mir die Funktion ExcelClose() genauer ansehen.

Vielen Dank für Ihre Aufmerksamkeit - Adrian

Answer 2

Ich glaube nicht, dass das Problem mit diesem Konstruktor ist.Versuchen Sie das Objekt dynamisch zu erstellen:

var obj = Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application")); 

wirft es dann zu Microsoft.Office.Interop.Excel.Application:

var xlApp = (Microsoft.Office.Interop.Excel.Application)obj; 
MessageBox.Show(xlApp.Name); 

ich erwarten würde die Verlangsamung auf den Activator.CreateInstance Anruf zu bewegen.

Wie auch immer, können Sie es versuchen, um zu arbeiten, indem sie die folgenden in Sie app.config Datei (more details) Platzierung:

<runtime> 
    <generatePublisherEvidence enabled="false"/> 
</runtime> 

ich auch sicher machen würde vorschlagen, Sie laufen die neuesten VSTO Runtime und die neueste Office PIAs.