2010-05-19 6 views
2

Je crée une activité de flux de travail personnalisée à utiliser dans TFS2010. Dans le même assemblage, j'ai une activité XAML et une activité de code C#. L'activité XAML référence l'activité de code. Lorsque l'assembly est déployé sur nos clients, je souhaite uniquement qu'ils puissent utiliser l'activité Workflow. L'activité de code est peu utile en elle-même et la confondrait sans aucun doute.Référence d'une classe interne à partir d'une activité Windows Workflow

Je pensais que la manière logique de le faire serait de définir la classe d'activité de code sur interne: le XAML est dans le même assembly et devrait être capable d'y accéder. Cependant, quand je fais cela, je reçois une erreur dans le XAML disant que le type ne peut pas être trouvé dans l'assemblage.

Existe-t-il un moyen de rendre les activités internes/masquées?

+0

Êtes-vous sûr que 'internal' est le problème? Avez-vous essayé la même action avec la classe définie sur 'public'? Ce pourrait être un problème d'espace de noms. –

+0

Oui, interne est le problème. Nous avons (et l'expédions avec) le modificateur mis à public, parce qu'il n'y avait pas d'autre moyen de le faire fonctionner :( –

+0

Je me demande si le problème est que l'activité de code n'est pas réellement référencée par votre code, mais par Voici une idée: mettre un point d'arrêt dans le constructeur de l'activité du code (déclaré public) et voir comment il est instancié. –

Répondre

1

Ceci est un problème courant avec XAML sous toutes ses formes. Il est causé par le fait (mentionné dans l'un des commentaires) que l'analyseur n'est pas dans le même assemblage, donc n'a pas accès aux internes de votre assemblée.

La solution de contournement que j'ai vue le plus souvent consiste simplement à séparer ce que vous voulez avoir comme interne dans son propre espace de noms. Au moins, vos consommateurs ne sont généralement pas dérangés par des types déroutants qu'ils n'ont pas besoin d'utiliser. Dans WPF cet espace de noms est généralement l'espace de noms principal avec ".Primitives" ajouté. par exemple. System.Windows.Controls.Primitives.

Une autre option que vous pourriez étudier est l'utilisation d'une NativeActivity personnalisée plutôt qu'une XAML. On peut supposer que cela pourrait utiliser des classes internes, puisque l'analyseur XAML n'est pas impliqué. Cependant, je n'ai pas testé cela.

Questions connexes