Comment puis-je commencer à concevoir et à mettre en œuvre une interface script pour mon application .NET ?

Question

Comment puis-je commencer à concevoir et à mettre en œuvre une interface script pour mon application .NET ?

Il y a VSTA (l'équivalent .NET de VBA pour COM ), mais d'après ce que j'ai compris, je devrais payer une licence pour chaque installation de mon application. Il s'agit d'une application open source donc cela ne fonctionnera pas.

Il y a aussi, par exemple, l'intégration d'interprètes (IronPython ?), mais je ne comprends pas comment cela pourrait permettre d'exposer un "modèle objet" (voir ci-dessous) à des scripts externes (ou internes).

Sous-questions :

• Quelle est l'histoire de l'interface de script dans .NET ? Est-il trivial de faire cela en .NET ?
• Par exemple, certains objets .NET de mon application et les objets qu'ils contiennent peuvent-ils être déclarés accessibles de l'extérieur au moment de l'exécution ?
• Comment externe Les scripts accèdent à mon application (via le modèle objet) ?

---

Le contexte :

J'ai déjà conçu et mis en œuvre une interface script assez complexe pour une application Macintosh d'acquisition et d'analyse de données provenant de un spectromètre de masse (Mac OS, Système 7 ) et plus tard une interface COM pour une application Windows.

Tous deux ont été conçus avec un "modèle objet" et des classes (qui peuvent avoir des propriétés). Ce sont des mots surchargés, mais dans le contexte d'une interface de script, le modèle objet est essentiellement une hiérarchie de confinement d'objets de classes spécifiques. Les classes ont des propriétés, des listes d'objets contenus et ne sont pas seulement des données mais peuvent aussi avoir des verbes (actions/méthodes). Par exemple, dans le cas du Macintosh, l'objet d'application défini peut contenir un objet d'acquisition qui a des propriétés pour les tensions utilisées dans l'instrument et un objet d'acquisition de données. fireLater verbe - tout cela vu depuis le script externe.

Notez que dans les deux cas, les classes/objets du langage de programmation utilisé pour mettre en œuvre l'application n'ont rien à voir avec le modèle objet de script. Dans le cas du Macintosh, les mécanismes utilisés pour mettre en œuvre l'interface de script ont été définis par Apple. Apple a également défini certaines normes sur la façon de concevoir le modèle objet. Par exemple, des noms standardisés pour certaines propriétés communes dans les classes.

Ou comme dans les interfaces COM exposées dans les applications Microsoft Office, où l'objet application peut être utilisé pour ajouter à sa liste de documents (avec l'effet secondaire de créer la représentation GUI d'un document).

Les scripts externes peuvent créer de nouveaux objets dans un conteneur et naviguer dans le contenu de la hiérarchie à tout moment. Dans le cas du Macintosh, les scripts peuvent être écrits, par exemple, dans le format AppleScript ou Frontière .

Sur le Macintosh, la mise en œuvre d'une interface de script était très compliquée. Le support de cette interface dans Metroworks Une bibliothèque de classes C++ (dont le nom m'échappe pour l'instant) a rendu les choses beaucoup plus simples.

Answer 1

Jetez un coup d'œil à PowerShell .

Il vous permet de programmer des Cmdlets simples qui sont scriptables. Il prend également en charge les conteneurs hiérarchiques (par défaut, vous avez le système de fichiers, le registre, le magasin de certificats, etc.)

Answer 2

[EDIT : Comme cela a été longuement évoqué dans les commentaires, en supposant que vous ayez un besoin important d'activer le scripting interne, où vous hébergez des snippets ou des fonctions que quelqu'un vous donne pour personnaliser votre application, par opposition à un scénario purement externe où l'on fournit une façade pour permettre aux gens d'extraire des choses de votre application sur une base prédéfinie plus rigide].

IronRuby et IronPython sont très soignés et appropriés pour cela (mais comme le dit l'autre réponse, PowerShell peut être approprié si vous avez un problème de type infrastructure).

EDIT : D'autres idées pour activer les scripts internes sont les suivantes

• utiliser Windows Workflow Foundation (en y exposant des activités et/ou en hébergeant des instances de workflows)
• en utilisant Le langage d'expression de Spring.NET (qui est concis, facile à lire et à apprendre, mais étonnamment puissant).

EDIT 2 juin 2011 : IronJS peut également être un candidat approprié, Il y a un Hanselminutes qui en parle. .

Answer 3

Je vous suggère de considérer le Exécution du langage dynamique comme stratégie de mise en œuvre d'une interface de script. Détails :

• Site de CodePlex DLR
• Présentation de MSDN .NET 4 DLR

Le DLR supporte actuellement IronPython et IronRuby ainsi qu'un certain nombre d'autres implémentations du langage peuvent être trouvées sur le site suivant CodePlex . Si vous souhaitez créer un langage spécifique à votre application, Bitwise Magazine propose une bonne introduction. article .

La session PDC09 de Dino Viehland Utilisation de langages dynamiques pour créer des applications scriptables vaut la peine d'être regardé. Vous pouvez trouver le code de la démo ici .

Answer 4

Le site Langage de script Lua est gratuit, utilisé dans un grand nombre d'applications commerciales et facilement intégrable dans une application .NET à l'aide de l'application gratuite LuaInterface qui vous permet d'exposer des types et des méthodes de votre application que les scripts de votre interpréteur intégré peuvent exploiter.

Un tutoriel sur la façon d'intégrer Lua dans une application C# peut être trouvé ici .

Edit : Il est probablement aussi intéressant de noter que Lua a été conçu dès le départ pour être un langage de script embarqué, et par conséquent, l'interpréteur est hautement personnalisable. L'application hôte peut restreindre presque tous les aspects des capacités d'interprétation dans le cadre du modèle de sécurité ; par exemple, autoriser ou empêcher les scripts d'établir des connexions réseau ou d'écrire dans des fichiers, etc.

Aussi, vous avez demandé externe scripts. La mise à disposition de votre programme pour les scripts hors processus s'effectue de la même manière que pour les applications hors processus : en exposant une interface d'automatisation standardisée via une sorte de protocole de communication. Sous Windows, pour la communication inter-processus entre machines, il s'agit le plus souvent de COM, mais aussi de WCF, de TCP remoting, de RPC ou de tout autre standard de communication. Ce que vous choisissez de faire dépend fortement de la façon dont votre application est construite et du type d'automatisation externe que vous souhaitez lui faire faire.

Answer 5

Pour une solution gratuite et facile à mettre en œuvre .NET langage de script, jetez un coup d'œil à C#.

Voir ma réponse à une question similaire.

Pour ce qui est de l'exposition des données, étant donné qu'il s'agit d'un langage .NET, il vous suffit d'ajouter votre programme aux assemblées à lier et de rendre les classes concernées publiques.