Question Précharger un assembly une bonne fois pour toute ?

Plus d'informations
il y a 13 ans 3 mois #13292 par Steph
Bonjour,

Pour simplifier mon problème: j'ai par exemple un script qui fait appel à un assembly SQLServer (Microsoft.SqlServer.SMO pour ne pas le nommer). Le chargement de cet assembly est long, ce qui ne serait pas un pb si je restais sur la meme session powershell; malheureusement, ce script est batché pour s'executer toutes les x minutes (lancement à travers un powershell -command \"<script>\", via l'ordonnanceur windows par exemple) et le temps de chargement de l'assembly est bcp trop penalisant par rapport à l'execution du script en lui meme.

Y a t il une technique pour pré-charger l'assembly une bonne fois pour toute (et valable pour toutes les futures sessions powershell) ?

J'ai essayé avec ngen, mais sans succès (ca se trouve, cela n'est pas du tout en rapport avec mon probleme).

Merci pour votre aide;

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 13 ans 3 mois #13294 par Matthew BETTON
Bonjour,

Peux tu mettre ici la méthode que tu utilises pour charger l'Assembly ?

@ +

Matthew

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 13 ans 3 mois #13295 par Steph
Par exemple (en V2):

[Reflection.Assembly]::LoadWithPartialName(\"Microsoft.SqlServer.Smo\")
$obj = new-object('Microsoft.SqlServer.Management.Smo.Server')

ou un :
Add-Type -path \"C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.Smo\10.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Smo.dll\"
$obj = new-object('Microsoft.SqlServer.Management.Smo.Server')


Un measure-command m'indique un temps de 13 sec pour charger l'assembly et 6 sec pour la creation de l'objet.

Une nouvelle execution dans la console est evidement instantané.

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 13 ans 3 mois #13303 par Laurent Dardenne
carpi751 écrit:

Y a t il une technique pour pré-charger l'assembly une bonne fois pour toute

Pas à ma connaissance. La console PS crée un domaine d'application dotnet dédié, et comme tous on doit y charger ce dont on a besoin.
carpi751 écrit:

(et valable pour toutes les futures sessions powershell) ?

Non. Peut être avec Makeit.exe, mais le temps chargement sera, à priori, identique.

Pour ton besoin, il te faudrait la v3 et les sessions persistantes, sous réserve de validation.

J'ai souvent le même besoin et je n'ai pas trouvé de solution pour le moment.
Une idée, un service windows dédié intégrant le framework PS qui resterait à l'écoute...

Autre possiblité en natif, communiquer avec une session PS V2 maître restant active. Ce n'est pas terrible, mais possible. Et dans cas comme la console PS n'a pas de 'pompe de message' cela devient tout suite une construction, comment dire, ah oui, de fortune. Mais ça fonctionne.
Ensuite de présenter cette solution et que ton responsable l'accepte, c'est une autre histoire :lol:

Tutoriels PowerShell

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 13 ans 3 mois #13304 par Matthew BETTON
A propos d'optimisation et de ngen :

De ce que je viens de lire ici et là, on peut \"espérer gagner du temps\" dans le temps de chargement de la console via ngen.exe.

Une discussion récente (mai 2012) sur le sujet

Pourtant, j'avais cru comprendre que cela avait été amélioré /corrigé avec la version 2 de PowerShell :

Un article de Jeffrey SNOVER et la suite ici .

this is a workaround for a V1 bug. This is fixed in V2.



Pour en revenir au temps de chargement de \"Microsoft.SqlServer.Smo\" : C'est directement sur un serveur SQL ou bien sur une machine d'administration, pour ensuite requêter un serveur SQL distant ? Sur une machine XP je ne constate pas ces temps... C'est bien plus rapide.

Aussi, LoadWithPartialName est obsolète .
Il est maintenant conseillé d'utiliser Load.

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 13 ans 3 mois #13306 par Steph
Effectivement ces temps sont mesurés sur un serveur hébergeant un moteur SQL server; je vais faire un test sur une workstation classique.

Pour ngen, j ai trifouillé dans tous les sens, sans succès. Je m y prends peut être mal; je vais aussi refaire une tentative.

Concernant la V3 et les sessions persistantes , ça peut être la solution.

Merci pour vos pistes en tout cas.

Connexion ou Créer un compte pour participer à la conversation.

Temps de génération de la page : 0.105 secondes
Propulsé par Kunena