[.NET 2.0] Programm braucht knapp 1 Minute zum laden

[Gast BeowulfOF]

Hallo zusammen,

vielleicht hat das auch schonmal jemand erlebt und kann mir weiterhelfen.

Mein Programm besteht aus ca 17 Assemblies, dazu kommen noch 8 referenzierte Asseblies von Infragistics.

Das Programm startet zügig, und läuft auch einwandfrei, allerdings, bevor es lädt, vergeht fast eine Minute Zeit, sofern der User ein Domänenuser ist.

Also, vom Doppelklicken auf die .exe, bis die erste Zeile im Code ausgeführt wird, vergeht diese Zeit. Das tritt sowohl auf, wenn wir den Code vom Netzwerk starten, als auch bei lokaler Ausführung. Unsere Assemblies sind alle signiert, und der StrongName wurde via Caspolicies als FullTrust Quelle ausgegeben. Zudem wurde KlickOnce aktiviert, die Anwendung hat ihr Manifest dabei.

Es scheint aber so, als ob die Runtime irgendwas abprüft, bevor der Code ausgeführt wird, nur bin ich leider total Ratlos, um was es sich da handeln könnte.

Bin für jeden Denkansatz dankbar.

BeowulfOF

[Honkytonk]

Hmm, klingt ja merkwürdig.

Das einzige was mir im Zusammenhang mit Zertifikaten einfällt, ist die Windows-interne Prüfung auf zurückgezogene Zertifikate. Könntest du mal in den "Internetoptionen" im Tabreiter "Erweitert" des betreffenden Rechners die Prüfung auf zurückgezogene Zertifikate deaktivieren? (siehe Anhang)

Bei Rechnern ohne Internetzugang produziert der nämlich gerne Timeouts...

Gruß,

Honky

[Gast BeowulfOF]

Die Idee ist gut, aber werden die Zertifikate auch geprüft, bei nicht Web-Anwendungen?

Warum kommt diese Verzögerung dann nicht, wenn man mit einem lokalen Benutzerkonto arbeitet?

[Honkytonk]

Guter Punkt.

Sind der lokale Benutzer und der Domänennutzer grundsätzlich mit den gleichen Rechten ausgestattet (in den gleichen Gruppen) bzw. existieren noch zusätzliche Computer-Richtlinien aus der Domäne?

Noch eine Frage zum Zertifikat, ich gehe davon aus es kommt von einer Root-CA und ist noch gültig? (sorry, wollte nur alles abklopfen)

Meine Überlegungen zielen in die Richtung:

-> Manifest installiert dein Zertifkat bei ClickOnce in den lokalen Zertifkatsspeicher.

->Bei lokal angemeldetem Benutzer wird logischerweise nur der lokale Zertifkatsspeicher zur Überprüfung ausgelesen. Bei einem angemeldeten Domänenbenutzer erfolgt der Roundtrip über das AD als erstes und dann erst lokal.

[Gast BeowulfOF]

Sind der lokale Benutzer und der Domänennutzer grundsätzlich mit den gleichen Rechten ausgestattet (in den gleichen Gruppen) bzw. existieren noch zusätzliche Computer-Richtlinien aus der Domäne?

Soweit ich weis, sind die Domänennutzer rechtlich eingeschränkt, wie konnten bisher auch nur mit dem lokalen AdminAccount testen, da wir keine anderen Zugänge haben.

Noch eine Frage zum Zertifikat, ich gehe davon aus es kommt von einer Root-CA und ist noch gültig? (sorry, wollte nur alles abklopfen)

Jetzt weis ich auch, was du meintest, ich habe ClickOnce in den Projekteinstellungen aktualisiert, aber kein Zertifikat für das ClickOnce Manifest angegeben. Das Signieren der Assemblies geschieht über einen StrongNameKey (.snk). Wir haben keine Zertifikate für unser Unternehmen ausgestellt.

Meine Überlegungen zielen in die Richtung:

-> Manifest installiert dein Zertifkat bei ClickOnce in den lokalen Zertifkatsspeicher.

->Bei lokal angemeldetem Benutzer wird logischerweise nur der lokale Zertifkatsspeicher zur Überprüfung ausgelesen. Bei einem angemeldeten Domänenbenutzer erfolgt der Roundtrip über das AD als erstes und dann erst lokal.

Das klingt logisch, allerdings wird halt kein Zertifikat beim ClickOnce angegeben. Kann es denn sein, dass das Framework trotzdem roundtrips macht? AD-Abragen sind im Kundennetz leider sehr langsam...

[Argbeil]

Hi, das ist nicht ungewöhnlich und kommt vermutlich durch den JIT Compiler sowie diverese CRC und Runtime Checks. (CAS) Du musst bedenken das durch die Signierung in Kombination mit ClickOnce erst die kompletten Assemblys zum Client übertragen werden müssen und im Anschluss die Signatur überprüft wird.

Versuch mal mit ngen.exe auf der Zielplattform die Assembly vorzukompilieren ohne Click-Once zu verwenden, hier sollte der Start deutlich schneller gehen. Wenn das nicht schneller geht prüf mit einem Profiler welche Methoden die längste Zeit benötigen. Übrigens ist das starten vom Netz nicht identisch mit einer lokalen Ausführung, kopier die Dateien mal nach c: auf dem Client und probier das nochmal.

Wenn in deiner Main Methode z.B. die Methoden a und b gerufen werden, werden a und b vorher kompiliert zusammen mit dem abhänigen Code. Wenn hier z.B. die Infragistic Controls verwendet werden kann das eine große Menge Code sein.

Du könntest einen Splash-Screen bauen, der in einem separatem Thread angezeigt wird. Nach dem starten des Threads machst du erst die Initialisierungen bzw. die ersten Calls auf die Infragistics Controls.

Dieses Performance-Leak könnte einer der Gründe sein das ClickOnce der große Druchbruch bisher verwehrt wurde.

[Gast BeowulfOF]

Hi, das ist nicht ungewöhnlich und kommt vermutlich durch den JIT Compiler sowie diverese CRC und Runtime Checks. (CAS) Du musst bedenken das durch die Signierung in Kombination mit ClickOnce erst die kompletten Assemblys zum Client übertragen werden müssen und im Anschluss die Signatur überprüft wird.

Wurde auch schon vermutet, allerdings ist dies keine Erklärung, warum es auf manchen Rechnern schnell und auf anderen langsam geht.

Versuch mal mit ngen.exe auf der Zielplattform die Assembly vorzukompilieren ohne Click-Once zu verwenden, hier sollte der Start deutlich schneller gehen. Wenn das nicht schneller geht prüf mit einem Profiler welche Methoden die längste Zeit benötigen. Übrigens ist das starten vom Netz nicht identisch mit einer lokalen Ausführung, kopier die Dateien mal nach c: auf dem Client und probier das nochmal.

Lokal oder Remote oder sogar vorkompiliert, ändert nichts an der Sache.

Wenn in deiner Main Methode z.B. die Methoden a und b gerufen werden, werden a und b vorher kompiliert zusammen mit dem abhänigen Code. Wenn hier z.B. die Infragistic Controls verwendet werden kann das eine große Menge Code sein.

Ebenfalls kein Grund, warum es manchmal schnell geht, und manchmal nicht. In der Main selber wird nur ein LogFile erstellt und dann das die Anwendung instanziiert, als Object... von da an läuft der Apparat erst an.

Du könntest einen Splash-Screen bauen, der in einem separatem Thread angezeigt wird. Nach dem starten des Threads machst du erst die Initialisierungen bzw. die ersten Calls auf die Infragistics Controls.

Das ist ja der Witz, ich habe beim laden der Anwendung einen "Splash" mit Progressbar, allerdings ist die Verzögerung, bevor dieser eben erst initialisiert wird. Vom Moment des Doppelklicks bis zur ersten ausgeführten Codezeile vergeht fast eine Minute.

Dieses Performance-Leak könnte einer der Gründe sein das ClickOnce der große Druchbruch bisher verwehrt wurde.

Das hat aber leider nichts mit ClickOnce zu tun. Ob ich CO aktiviere oder nicht, ändert mal rein gar nichts, leider.

Inzwischen haben wir rausgefunden, dass es scheinbar am Netzwerk liegt, in machen SubDomains ist der Programmstart schnell (2-3 Sek) und in anderen SubDomains dauert es halt knapp eine Minute. (SubDomains also vom AD-Tree her gesehen.)

MFG BeowulfOF