Comment charger des assemblys dans PowerShell?

Le code PowerShell suivant

#Get a server object which corresponds to the default instance
$srv = New-Object -TypeName Microsoft.SqlServer.Management.SMO.Server
... rest of the script ...

Donne le message d'erreur suivant:

New-Object : Cannot find type [Microsoft.SqlServer.Management.SMO.Server]: make sure 
the assembly containing this type is loaded.
At C:\Users\sortelyn\ ... \tools\sql_express_backup\backup.ps1:6  char:8
+ $srv = New-Object -TypeName Microsoft.SqlServer.Management.SMO.Server
+        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidType: (:) [New-Object], PSArgumentException
+ FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewObjectCommand

Chaque réponse sur Internet écrit que je dois charger l'assemblage - bien sûr que je peux lire cela à partir du message d'erreur :-) - la question est:

Comment charger l'assemblage et faire fonctionner le script?

LoadWithPartialNameest obsolète. La solution recommandée pour PowerShell V3 consiste à utiliser l' Add-Typeapplet de commande, par exemple:

Add-Type -Path 'C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies\Microsoft.SqlServer.Smo.dll'

Il existe plusieurs versions différentes et vous souhaiterez peut-être choisir une version particulière. :-)

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo")

La plupart des gens savent maintenant que System.Reflection.Assembly.LoadWithPartialNamec'est obsolète, mais il s'avère que Add-Type -AssemblyName Microsoft.VisualBasic cela ne se comporte pas beaucoup mieux queLoadWithPartialName :

Plutôt que de tenter d'analyser votre requête dans le contexte de votre système, [Add-Type] examine une table interne statique pour traduire le «nom partiel» en «nom complet».

Si votre "nom partiel" n'apparaît pas dans leur tableau, votre script échouera.

Si plusieurs versions de l'assemblage sont installées sur votre ordinateur, il n'y a pas d'algorithme intelligent pour choisir entre elles. Vous obtiendrez celui qui apparaît dans leur tableau, probablement le plus ancien et obsolète.

Si les versions que vous avez installées sont toutes plus récentes que la version obsolète du tableau, votre script échouera.

Add-Type n'a pas d'analyseur intelligent de "noms partiels" comme .LoadWithPartialNames.

Qu'est - ce que Microsoft dit que vous êtes réellement censé faire quelque chose comme ceci:

Add-Type -AssemblyName 'Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Ou, si vous connaissez le chemin, quelque chose comme ceci:

Add-Type -Path 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualBasic\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.dll'

Ce nom long donné pour l'assembly est connu sous le nom de nom fort , qui est à la fois unique à la version et à l'assembly, et est également parfois appelé nom complet.

Mais cela laisse quelques questions sans réponse:

1. Comment déterminer le nom fort de ce qui est réellement chargé sur mon système avec un nom partiel donné?

   [System.Reflection.Assembly]::LoadWithPartialName($TypeName).Location; [System.Reflection.Assembly]::LoadWithPartialName($TypeName).FullName;

Ceux-ci devraient également fonctionner:

Add-Type -AssemblyName $TypeName -PassThru | Select-Object -ExpandProperty Assembly | Select-Object -ExpandProperty FullName -Unique

2. Si je veux que mon script utilise toujours une version spécifique d'un .dll mais que je ne peux pas être certain de l'endroit où il est installé, comment déterminer quel est le nom fort du .dll?

   [System.Reflection.AssemblyName]::GetAssemblyName($Path).FullName;

Ou:

Add-Type $Path -PassThru | Select-Object -ExpandProperty Assembly | Select-Object -ExpandProperty FullName -Unique

3. Si je connais le nom fort, comment puis-je déterminer le chemin .dll?

   [Reflection.Assembly]::Load('Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a').Location;

4. Et, dans le même ordre d'idées, si je connais le nom de type de ce que j'utilise, comment savoir de quel assemblage il provient?

   [Reflection.Assembly]::GetAssembly([Type]).Location [Reflection.Assembly]::GetAssembly([Type]).FullName

5. Comment voir quels assemblages sont disponibles?

Je suggère le module GAC PowerShell . Get-GacAssembly -Name 'Microsoft.SqlServer.Smo*' | Select Name, Version, FullNamefonctionne plutôt bien.

6. Comment puis-je voir la liste qui Add-Typeutilise?

C'est un peu plus complexe. Je peux décrire comment y accéder pour n'importe quelle version de PowerShell avec un réflecteur .Net (voir la mise à jour ci-dessous pour PowerShell Core 6.0).

Tout d'abord, déterminez de quelle bibliothèque Add-Typeprovient:

Get-Command -Name Add-Type | Select-Object -Property DLL

Ouvrez la DLL résultante avec votre réflecteur. J'ai utilisé ILSpy pour cela parce que c'est FLOSS, mais n'importe quel réflecteur C # devrait fonctionner. Ouvrez cette bibliothèque et regardez dedans Microsoft.Powershell.Commands.Utility. En dessous Microsoft.Powershell.Commands, il devrait y en avoir AddTypeCommand.

Dans le code inscripteur pour cela, il y a une classe privée, InitializeStrongNameDictionary(). Cela répertorie le dictionnaire qui mappe les noms courts aux noms forts. J'ai regardé près de 750 entrées dans la bibliothèque.

Mise à jour: maintenant que PowerShell Core 6.0 est open source. Pour cette version, vous pouvez ignorer les étapes ci-dessus et voir le code directement en ligne dans leur référentiel GitHub . Cependant, je ne peux pas garantir que ce code correspond à une autre version de PowerShell.

Si vous souhaitez charger un assembly sans le verrouiller pendant la durée de la session PowerShell , utilisez ceci:

$bytes = [System.IO.File]::ReadAllBytes($storageAssemblyPath)
[System.Reflection.Assembly]::Load($bytes)

Où $storageAssemblyPathest le chemin de fichier de votre assembly.

Ceci est particulièrement utile si vous avez besoin de nettoyer les ressources de votre session. Par exemple dans un script de déploiement.

Voici quelques articles de blog avec de nombreux exemples de façons de charger des assemblys dans PowerShell v1, v2 et v3.

Les moyens comprennent:

• dynamiquement à partir d'un fichier source
• dynamiquement à partir d'un assemblage
• en utilisant d'autres types de code, par exemple F #

v1.0 Comment charger des assemblys .NET dans une session PowerShell
v2.0 à l' aide de code CSharp (C #) dans des scripts PowerShell 2.0
v3.0 à l' aide d' assemblys .NET Framework dans Windows PowerShell

Vous pouvez charger l'ensemble de l'assembly * .dll avec

$Assembly = [System.Reflection.Assembly]::LoadFrom("C:\folder\file.dll");

Aucune des réponses ne m'a aidé, donc je poste la solution qui a fonctionné pour moi, tout ce que j'avais à faire est d'importer le module SQLPS, je m'en suis rendu compte lorsque par accident j'ai exécuté la commande Restore-SqlDatabase et j'ai commencé à travailler, ce qui signifie que l'assemblage a été référencé dans ce module d'une manière ou d'une autre.

Exécutez simplement:

Import-module SQLPS

Remarque: merci Jason d'avoir noté que SQLPS est obsolète

à la place, exécutez:

Import-Module SqlServer

ou

Install-Module SqlServer

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") travaillé pour moi.

Vous pourriez utiliser LoadWithPartialName. Cependant, cela est obsolète comme ils l'ont dit.

Vous pouvez en effet accepter Add-Type, et en plus des autres réponses, si vous ne souhaitez pas spécifier le chemin complet du fichier .dll, vous pouvez simplement faire:

Add-Type -AssemblyName "Microsoft.SqlServer.Management.SMO"

Pour moi, cela a renvoyé une erreur, car SQL Server n'est pas installé (je suppose), cependant, avec cette même idée, j'ai pu charger l'assembly Windows Forms:

Add-Type -AssemblyName "System.Windows.Forms"

Vous pouvez trouver le nom d'assembly précis appartenant à la classe particulière sur le site MSDN:

Assurez-vous que les fonctionnalités ci-dessous sont installées dans l'ordre

1. Types de CLR système Microsoft pour SQL Server
2. Objets de gestion partagée Microsoft SQL Server
3. Extensions Microsoft Windows PowerShell

Vous devrez peut-être également charger

Add-Type -Path "C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies\Microsoft.SqlServer.Smo.dll"
Add-Type -Path "C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies\Microsoft.SqlServer.SqlWmiManagement.dll"

Ajoutez les références d'assemblage en haut.

#Load the required assemblies SMO and SmoExtended.
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoExtended") | Out-Null