Fichier de configuration d’application (ACF)

Il peut y avoir des aspects de votre application distribuée qui affectent un composant, mais qui n’ont rien à voir avec un autre. Par exemple, un objet peut contenir une structure de données volumineuse et complexe et passer 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 destinataire. 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 de marshaling et de démarshalation.

Les applications clientes peuvent partager la même interface, mais s’exécuter sur des plateformes différentes ; ils peuvent chacun avoir besoin de leur propre ensemble de routines de marshaling. Enfin, les clients individuels n’ont pas toujours besoin du même ensemble de fonctions. Il est inefficace de générer du code stub pour des 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/ acf du compilateur MIDL pour spécifier explicitement un nom de fichier ACF, les noms d’interface n’ont pas besoin de correspondre. Cette fonctionnalité permet à plusieurs interfaces de partager une seule spécification ACF.