2009-02-07 4 views
2

Pour un de mes projets, j'ai besoin de générer des classes au moment de l'exécution, et je pensais que ce serait assez simple avec Reflection.Emit, mais je reçois des exceptions MemberAccess quand j'exécute du code généré qui appelle des méthodes qui sont marqués à l'intérieur de l'assemblage du générateur. Est-il possible de dire à l'exécution que l'assembly dynamique devrait pouvoir accéder directement à mon propre code? Je préfère vraiment ne pas exposer publiquement aucun de ces membres aux consommateurs de ma bibliothèque. En ce qui concerne InternalsVisibleTo, je ne sais pas comment je pourrais l'utiliser dans le cas d'assemblages générés dynamiquement. Est-ce seulement possible?Comment autoriser les assemblys Reflection.Emit à accéder aux membres internes de l'assemblage de génération?

+0

Avez-vous essayé InternalsVisibleTo? – tuinstoel

Répondre

3

InternalsVisibleTo fonctionne en ouvrant un assemblage à d'autres. Ainsi, si vous souhaitez utiliser l'assembly Foo à partir de vos types générés, vous devez spécifier le nom de l'assembly généré dans AssemblyInfo.cs pour Foo.

Si vous émettez un nouvel assembly à l'aide de la classe AssemblyBuilder, vous pouvez spécifier le nom de l'assembly généré. Ce nom doit correspondre au nom utilisé pour l'attribut InternalsVisibleTo dans l'assembly Foo.

0

Je suppose qu'il y a une raison derrière le fait que les membres de votre groupe de production sont marqués comme internes. Vous pouvez exposer les fonctionnalités nécessaires dans les méthodes publiques, ou vous n'avez plus que deux choix: InternalsVisibleTo (comme @tuinstoel mentionné dans la section des commentaires) ou Reflection (en utilisant la réflexion, vous pouvez accéder aux membres non publics dans différents assemblages) .

+0

Je ne sais pas comment je pourrais l'utiliser dans le cas d'assemblages générés dynamiquement. Est-ce seulement possible? –

Questions connexes