8
Word Schnellstarter (im Hintergrund)
Hallo zusammen,
bei einem Kunden verzögert ein COM-AddIn den Start von Word um ~ 6-7 Sekunden (von normalen 0.2 Sekunden).
Szenario:
Microsoft Office 2019
Windows 10 oder TerminalServer2019 (identisches Verhalten)
Ziel:
Office-Programme (primär Word) im Hintergrund vorladen. Sobald der Winword.exe Prozess einmal geladen ist, werden bei den nächsten Dokumenten die COM-AddIns nicht nochmal nachgeladen. Das konnte ich bereits erfolgreich nachstellen.
Welchen Weg sollte ich einschlagen:
Da ich keinen Office-Schnellstart (mehr) finde hier ein paar Ideen, die ich gerne mal in der Runde diskutieren möchte:
- Gibt es noch einen Schnellstart, der die Office-Programme vorladen kann? (Sowas war doch mal bei den alten Office-Paketen dabei, oder war das nur bei OO?)
- Ich habe mit SilentRun ein wenig "herumgespielt", das funktioniert lokal recht gut, auf den TerminalServern leider keine Option (zu fehleranfällig und via CLI kann ich Programme nur eine gewisse Zeit lang starten - Parameter t=xxx)
- Gibt es weitere Programme, die sowas leisten?
- Was eigenes implementieren?
- Andere Ansätze?
Hat jemand Erfahrungen mit diesem Szenario oder sogar schon eine Lösung oder eleganten Ansatz parat?
Freue mich auf euer Feedback
Grüße Sudsaat
bei einem Kunden verzögert ein COM-AddIn den Start von Word um ~ 6-7 Sekunden (von normalen 0.2 Sekunden).
Szenario:
Microsoft Office 2019
Windows 10 oder TerminalServer2019 (identisches Verhalten)
Ziel:
Office-Programme (primär Word) im Hintergrund vorladen. Sobald der Winword.exe Prozess einmal geladen ist, werden bei den nächsten Dokumenten die COM-AddIns nicht nochmal nachgeladen. Das konnte ich bereits erfolgreich nachstellen.
Welchen Weg sollte ich einschlagen:
Da ich keinen Office-Schnellstart (mehr) finde hier ein paar Ideen, die ich gerne mal in der Runde diskutieren möchte:
- Gibt es noch einen Schnellstart, der die Office-Programme vorladen kann? (Sowas war doch mal bei den alten Office-Paketen dabei, oder war das nur bei OO?)
- Ich habe mit SilentRun ein wenig "herumgespielt", das funktioniert lokal recht gut, auf den TerminalServern leider keine Option (zu fehleranfällig und via CLI kann ich Programme nur eine gewisse Zeit lang starten - Parameter t=xxx)
- Gibt es weitere Programme, die sowas leisten?
- Was eigenes implementieren?
- Andere Ansätze?
Hat jemand Erfahrungen mit diesem Szenario oder sogar schon eine Lösung oder eleganten Ansatz parat?
Freue mich auf euer Feedback
Grüße Sudsaat
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4846080083
Url: https://administrator.de/contentid/4846080083
Printed on: April 27, 2024 at 19:04 o'clock
8 Comments
Latest comment
Ahoi!
Quick n Dirty mit Powershell
Oder VBS
Quick n Dirty mit Powershell
(New-Object -ComObject Word.Application).Quit()CreateObject("Word.Application").Quit 
Ahoi abramakabra,
danke für dein Feedback - hab das gleich mal auf einem Client via PowerShell nachgestellt.
Der Befehl erzeugt auch erfolgreich ein Word-Prozess im Hintergrund, beendet diesen aber auch schnell wieder, vermutlich mittels API .quit()
Ich habe den Befehl mal ohne direktes Beenden ausgeführt, dann hält das ganze bis zum nächsten Start von Word und dieser ist extrem schnell (wie angestrebt), allerdings hält es nicht für die darauf folgenden Starts von Word - diese sind dann wieder komplett langsam und laden dann auch die COM-AddIns wieder nach (ersichtlich direkt im Splash von Office beim Start).
D.h. starte ich via PowerShell den Prozess, ist das nächste Öffnen von Word performant. Sobald der Benutzer aber das neu geöffnete Word wieder schließt (mittels "X") ist der nächste Start wieder langsam (bzw. nicht vorgeladen)
Gibt es hier eine Möglichkeit, ein "hidden" Word permanent im Hintergrund geladen zu lassen?
Grüße Sudsaat
danke für dein Feedback - hab das gleich mal auf einem Client via PowerShell nachgestellt.
Der Befehl erzeugt auch erfolgreich ein Word-Prozess im Hintergrund, beendet diesen aber auch schnell wieder, vermutlich mittels API .quit()
Ich habe den Befehl mal ohne direktes Beenden ausgeführt, dann hält das ganze bis zum nächsten Start von Word und dieser ist extrem schnell (wie angestrebt), allerdings hält es nicht für die darauf folgenden Starts von Word - diese sind dann wieder komplett langsam und laden dann auch die COM-AddIns wieder nach (ersichtlich direkt im Splash von Office beim Start).
D.h. starte ich via PowerShell den Prozess, ist das nächste Öffnen von Word performant. Sobald der Benutzer aber das neu geöffnete Word wieder schließt (mittels "X") ist der nächste Start wieder langsam (bzw. nicht vorgeladen)
Gibt es hier eine Möglichkeit, ein "hidden" Word permanent im Hintergrund geladen zu lassen?
Grüße Sudsaat
Du bekämpfst nur die Symptome nicht die Ursache. Da würde ich an meiner Stelle als erstes ansetzen.
Falls das ein .NET Plugin sein sollte könntest du das Assembly in den vorgehaltenen .NET Cache laden.
https://learn.microsoft.com/en-us/dotnet/framework/app-domains/install-a ...
Falls das ein .NET Plugin sein sollte könntest du das Assembly in den vorgehaltenen .NET Cache laden.
https://learn.microsoft.com/en-us/dotnet/framework/app-domains/install-a ...
Zitat von @11078840001:
Du bekämpfst nur die Symptome nicht die Ursache. Da würde ich an meiner Stelle als erstes ansetzen.
Du bekämpfst nur die Symptome nicht die Ursache. Da würde ich an meiner Stelle als erstes ansetzen.
Hmm.. verstehe ich nicht ganz. Die Ursache ist doch, dass bei jedem Start von Word ein COM-AddIn geladen wird.
Das einmalige Starten von Word vorab reicht nicht aus - das AddIn wird beim nächsten Start von Word trotzdem erneut geladen (außer es existiert bereits ein Word-Prozess). D.h. schließt der Benutzer das einzige/letzte Word-Dokument wird beim nächsten Start von Word wieder alles verzögert durch das Laden dieses AddIns.
Daher ist mir nicht ganz klar, wie ich der Ursache entgegen wirken könnte ohne einen Word-Prozess im Hintergrund vorzuhalten (quasi klassisches Verhalten eines Schnellstarters).
Zitat von @11078840001:
Falls das ein .NET Plugin sein sollte könntest du das Assembly in den vorgehaltenen .NET Cache laden.
https://learn.microsoft.com/en-us/dotnet/framework/app-domains/install-a ...
Falls das ein .NET Plugin sein sollte könntest du das Assembly in den vorgehaltenen .NET Cache laden.
https://learn.microsoft.com/en-us/dotnet/framework/app-domains/install-a ...
Ein Caching klingt sinnvoll - ich weiß allerdings über das Plugin bisher recht wenig, außer dass es ein COM AddIn ist und mit ner .dll, .dll.config, .dll.manifest und der .vsto um die Ecke kommt (und das Starten von Word verzögert
.Der Hersteller ist hier leider auch keine große Hilfe - da warten wir bereits seit Tagen auf ein Feedback...
Hast du einen konkreten Ansatz, den ich austesten könnte?
Grüße Sudsaat
Nachtrag: Sorry, jetzt verstehe ich erst deine 1. Antwort (nachdem ich meine Frage nochmal durchgelesen habe, die auch irreführend formuliert ist - sorry):
...Sobald der Winword.exe Prozess einmal geladen ist, werden bei den nächsten Dokumenten die COM
AddIns nicht nochmal nachgeladen...
AddIns nicht nochmal nachgeladen...
Hier fehlt die Info, dass dies nur gilt, sofern der Prozess auch noch aktiv ist. Beim Beenden aller Word-Prozesse beginnt mit dem nächsten Start das "Drama" wieder von vorne.
Sorry
5> Zitat von @sudsaat:
Ein Caching klingt sinnvoll - ich weiß allerdings über das Plugin bisher recht wenig, außer dass es ein COM AddIn ist und mit ner .dll, .dll.config, .dll.manifest und der .vsto um die Ecke kommt (und das Starten von Word verzögert.
VSTO, dann ist es ein .NET Plugin, die sind berüchtigt dafür das sie etwas "warmup" benötigen.
Lade das Assembly mal in den globalen Cache testweise mit gacutil
https://learn.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac ...
Das sollte das ganze dann beschleunigen sofern das Plugin hier selbst nicht die Verzögerung in seinem Code verursacht.
Ein Caching klingt sinnvoll - ich weiß allerdings über das Plugin bisher recht wenig, außer dass es ein COM AddIn ist und mit ner .dll, .dll.config, .dll.manifest und der .vsto um die Ecke kommt (und das Starten von Word verzögert
.Lade das Assembly mal in den globalen Cache testweise mit gacutil
https://learn.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac ...
gacutil /i mydll.dll
super, werde ich definitiv austesten - muss das util erst noch auf dem Testclient bereitstellen. Ich werde berichten..
Vielen Dank für dein schnelle Feedback!
Grüße Sudsaat
Vielen Dank für dein schnelle Feedback!
Grüße Sudsaat
Zitat von @11078840001:
Lade das Assembly mal in den globalen Cache testweise mit gacutil
https://learn.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac ...
Das sollte das ganze dann beschleunigen sofern das Plugin hier selbst nicht die Verzögerung in seinem Code verursacht.
Lade das Assembly mal in den globalen Cache testweise mit gacutil
https://learn.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac ...
gacutil /i mydll.dllHabe ich heute auf einem lokalen Test-PC als auch auf einem TerminalServer getestet. Leider keine Veränderung. Das Plugin verzögert weiterhin den Start von Word. Gefühlt (nicht gemessen) von der Geschwindigkeit das gleiche.
Weitere Ideen jederzeit willkommen..
Grüße Sudsaat
Hallo nochmal,
ich habe gerade mal einen schnellen Wurf mittels VBS probiert und kann mit dem folgenden Snippet auch ein Word im Hintergrund (hidden) erzeugen:
Allerdings mit folgendem Nachteil - beim manuellen Start "erkennt" Word, dass dies eine neue Instanz ist und bringt diese in den Vordergrund (anstatt ein neues zu laden).
OK, mit dieser Erfahrung versuche ich dann ein konkretes Dokument im Hintergrund zu laden:
Jetzt wird beim manuellen Starten von Word eine neue Instanz verwendet (und lädt auch pfeilschnell), ABER mit den beiden zusätzlichen Parametern startet Word wieder im Vordergrund?!?
Hat jemand hierzu eine Idee?
Grüße Sudsaat
ich habe gerade mal einen schnellen Wurf mittels VBS probiert und kann mit dem folgenden Snippet auch ein Word im Hintergrund (hidden) erzeugen:
Dim objShell
Set objShell = CreateObject("Shell.Application")
Call objShell.ShellExecute("WINWORD.exe", "", "", "open", 0) Allerdings mit folgendem Nachteil - beim manuellen Start "erkennt" Word, dass dies eine neue Instanz ist und bringt diese in den Vordergrund (anstatt ein neues zu laden).
OK, mit dieser Erfahrung versuche ich dann ein konkretes Dokument im Hintergrund zu laden:
Dim objShell
Set objShell = CreateObject("Shell.Application")
Call objShell.ShellExecute("WINWORD.exe", "Schnellstart.docx", "E:\tmp", "open", 0) Jetzt wird beim manuellen Starten von Word eine neue Instanz verwendet (und lädt auch pfeilschnell), ABER mit den beiden zusätzlichen Parametern startet Word wieder im Vordergrund?!?
Hat jemand hierzu eine Idee?
Grüße Sudsaat
