Comment puis-je accéder à une bibliothèque de types à partir d'un script ?

S'il vous plaît Monsieur Script...

Bienvenue dans cette section TechNet, dans laquelle le Monsieur Script de Microsoft répond aux questions récurrentes sur les scripts d'administration système.

Question du jour : comment puis-je accéder à une bibliothèque de types à partir d'un script ?

Comment puis-je accéder à une bibliothèque de types à partir d'un script ?Comment puis-je accéder à une bibliothèque de types à partir d'un script ?

S'il vous plaît Monsieur Script... Comment puis-je accéder à une bibliothèque de types à partir d'un script ?

-- XA

Bonjour XA. Pour ceux qui ne connaissent pas l'expression, une bibliothèque de types est un fichier ou un composant qui contient des informations de type sur un objet COM. Les informations de type décrivent l'objet et la façon dont vous pouvez l'utiliser. Ces informations incluent également les constantes utilisées par l'objet. Par exemple, l'objet FileSystemObject inclut les trois constantes suivantes et leurs valeurs respectives :

ForReading (1)
ForWriting (2)
ForAppending (8)

Vous vous demandez peut-être quel est l'intérêt de toute cette explication. Et bien, chaque fois que vous accédez à un fichier texte à l'aide de l'objet FileSystemObject, vous devez faire référence à l'une de ces constantes. Par exemple, imaginons que vous souhaitez ouvrir le fichier C:\Scripts\Test.doc pour y écrire la date et l'heure en cours. Pour y parvenir, vous avez besoin d'un script similaire à celui-ci :

Const ForWriting = 2

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile _
    ("c:\scripts\test.txt", ForWriting)

objTextFile.WriteLine Now
objTextFile.Close

Vous remarquerez ici deux détails importants. Tout d'abord, lorsque nous ouvrons le fichier (à l'aide de la méthode OpenTextFile), nous incluons la constante ForWriting, car nous devons indiquer à l'objet FileSystemObject si le fichier est ouvert pour lecture, écriture ou ajout. Enfin, remarquez que, dans la toute première ligne du script, nous avons attribué explicitement la valeur 2 à la constante ForWriting. Cela s'explique par le fait que VBScript n'a pas accès aux bibliothèques de types. Par conséquent, nous devons indiquer à notre script que la valeur de ForWriting est 2.

En revanche, les langages de programmation comme Visual Basic peuvent accéder directement à une bibliothèque de types. Si nous étions en train d'écrire un programme Visual Basic, nous n'aurions pas besoin de définir la constante ForWriting ni de lui attribuer la valeur 2. Il nous suffirait d'inclure la constante dans notre code pour que Visual Basic accède à la bibliothèque de types et retrouve la valeur de ForWriting pour nous.

En d'autres termes, comme les langages de programmation ont accès aux bibliothèques de types, vous n'avez pas besoin de définir les constantes qu'elles contiennent. VBScript n'a pas accès aux bibliothèques de types. Par conséquent, vous devez définir manuellement toute constante utilisée dans votre script. (Vous pouvez même, dans certains cas, comme lors de l'utilisation d'ADO pour écrire des scripts qui interagissent avec des bases de données, être amené à utiliser des dizaines et des dizaines de constantes et à définir chacune d'entre elles.)

Vous êtes sûrement en train de vous dire « Allez, donnez-nous la solution, nous savons que vous en avez une ». Et vous avez raison, car nous avons trouvé le moyen de contourner le problème. Si vous écrivez un script VBScript « traditionnel » (c'est-à-dire un script qui porte l'extension de fichier .vbs), vous n'avez pas de chance. Mais si vous souhaitez écrire un fichier script Windows (avec l'extension .wsf), alors là, c'est une autre histoire.

Les fichiers WSF ont été utilisés pour la première fois dans WSH 5.6 et, pour être honnête, ils n'ont pas eu beaucoup de succès depuis. (Pour plus d'informations, consultez la page WSF documentation [en anglais] sur MSDN.) Le problème avec les fichiers WSF, c'est que les avantages qu'ils procurent (comme l'accès à une bibliothèque de types) ne suffisent pas à compenser l'inconvénient d'avoir à remplir son script de milliers de balises XML. Ceci dit, si XML ne vous pose pas de problème et que vous souhaitez réellement avoir accès aux bibliothèques de types, alors vous pouvez utiliser le type de code ci-dessous. (Assurez-vous de bien enregistrer ce script en tant que fichier .wsf et non .vbs.)

<package>
    <job id="Test">
        <object id="objFSO" progid="Scripting.FileSystemObject"/>
         <reference object="Scripting.FileSystemObject" />
            <script language="VBScript">
                Set objTextFile = objFSO.OpenTextFile _
                    ("c:\scripts\test.txt", ForWriting)
                objTextFile.WriteLine Now
                objTextFile.Close   
            </script>
    </job>
</package>

C'est sûr que les fichiers WSF ont l'air bizarre. C'est pourquoi, d'ailleurs, très peu de gens les utilisent. Si vous observez le contenu de la balise <script> (car c'est là que vous placez votre code VBScript), vous pouvez y voir le script que nous avons utilisé précédemment, à deux exceptions près : vous ne trouverez pas de code pour créer l'objet FileSystemObject ni pour définir la constante ForWriting. Nous utilisons à la place les balises <object> et <reference>, qui se chargent de la réalisation de ces deux tâches.

Dans notre script VBScript standard, nous avons utilisé la ligne de code suivante pour créer une instance de FileSystemObject :

Set objFSO = CreateObject("Scripting.FileSystemObject")

Dans le fichier WSF, nous utilisons la balise <object>, qui remplit la même fonction :

<object id="objFSO" progid="Scripting.FileSystemObject"/>

Remarquez l'ID attribué à l'objet : objFSO ; il s'agit de la même référence d'objet que celle que nous avons utilisée dans notre fichier .vbs.

Une fois la référence d'objet créée, nous pouvons accéder à la bibliothèque de types (et à toutes les constantes qui y sont définies) à l'aide de la balise <reference> :

<reference object="Scripting.FileSystemObject" />

À présent, nous pouvons faire référence à n'importe quelle constante trouvée dans FileSystemObject sans avoir à la définir. Simple, n'est-ce pas ? Bien évidemment, ce n'est pas toujours aussi simple. Il se peut que vous ayez à utiliser parfois un GUID plutôt qu'un ProgId (comme « Scripting.FileSystemObject ») lors de la création d'un objet et d'une référence. Mais ceci vous aura au moins servi de point de départ.

Pour en savoir plus

Consultez les archives de S'il vous plaît Monsieur Script...