从 Windows 工作流活动引用内部类
我正在创建一个在 TFS2010 中使用的自定义工作流活动。在同一个程序集中，我有一个 XAML 活动和一个 C# 代码活动。 XAML 活动引用代码活动。
当程序集部署到我们的客户时，我只希望他们能够使用工作流活动。代码活动本身没什么用处，并且无疑会让他们感到困惑。
我认为执行此操作的逻辑方法是将代码活动类设置为内部：XAML 位于同一个程序集中，并且应该能够访问它。但是，当我这样做时，我在 XAML 中收到错误，指出在程序集中找不到该类型。
有没有办法使活动内部/隐藏？
I'm creating a custom Workflow activity for use within TFS2010. In the same assembly I have a XAML activity and a C# code activity. The XAML activity references the code activity.
When the assembly is deployed to our clients, I only want them to be able to use the Workflow activity. The code activity is of little use by itself and would no doubt confuse them.
I thought the logical way to do this would be to set the code activity class to internal: the XAML is in the same assembly and should be able to access it. However, when I do that I get an error in the XAML saying that the type can't be found in the assembly.
Is there a way to make activities internal/hidden?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是所有形式的 XAML 的常见问题。这是由于解析器不在同一个程序集中（在评论之一中提到）这一事实引起的，因此无法访问程序集的内部结构。
我最常看到的解决方法就是将您想要的内部内容分离到自己的命名空间中。至少这样您的消费者通常不会被他们不需要使用的令人困惑的类型所困扰。在 WPF 中，此命名空间通常是主命名空间，并附加“.Primitives”。例如System.Windows.Controls.Primitives。
您可以研究的另一种方法是使用自定义 NativeActivity 而不是 XAML。据推测，这可以使用内部类，因为不涉及 XAML 解析器。不过我还没有测试过。
This is a common problem with XAML in all its forms. It's caused by the fact (mentioned in one of the comments) that the parser isn't in the same assembly, so has no access to internals of your assembly.
The work-around that I've seen most frequently is just to separate out what you'd like to have as internal into its own namespace. At least then your consumers aren't typically bothered by confusing types that they don't need to use. In WPF this namespace is usually the main namespace with ".Primitives" appended to it. e.g. System.Windows.Controls.Primitives.
Another tack that you could investigate is using a custom NativeActivity rather than a XAML one. Presumably this could use internal classes, since the XAML parser isn't involved. I've not tested this out though.