Fichier de configuration d’application (ACF)

Il peut y avoir des aspects de votre application distribuée qui affectent un composant, mais n’ont rien à voir avec un autre. Par exemple, un objet peut contenir une structure de données volumineuse et complexe et transmettre le contenu de cette structure de données à un autre objet. La disposition exacte de cette structure de données peut être sans signification pour l’application de réception. En outre, la structure peut contenir des types de données que le compilateur MIDL ne reconnaît pas et ne peut pas générer de code marshaling et unmarshaling.

Les applications clientes peuvent partager la même interface, mais s’exécuter sur différentes plateformes ; ils peuvent chacun avoir besoin de leur propre ensemble de routines de marshaling. Enfin, les clients individuels n’ont peut-être pas toujours besoin du même ensemble de fonctions. Il est inefficace de générer du code stub pour les fonctions qui ne seront jamais implémentées dans une application cliente particulière.

En définissant ces aspects locaux de votre interface dans un fichier de configuration d’application (ACF), vous pouvez séparer les différences entre les interfaces clientes de leur représentation réseau, ce qui permet au serveur d’envoyer et de recevoir des données dans un format cohérent et de rendre votre code stub plus compact et plus efficace.

La structure et la syntaxe d’une définition d’interface ACF sont identiques à la définition IDL :

[ interface-attribute-list] interface interface-name {. . .}

Par défaut, le nom de l’interface ACF doit correspondre à son nom dans la définition IDL. Toutefois, lorsque vous utilisez l’option du compilateur MIDL / acf pour spécifier explicitement un nom de fichier ACF, les noms d’interface n’ont pas à correspondre. Cette fonctionnalité permet à plusieurs interfaces de partager une seule spécification ACF.