Do you use Internal Types in Xaml (if you compile to Baml)? Why? Should Silverlight enable?
WPF enables you to refer to Public or Internal types in Xaml. Internal types only work at runtime if they are loaded from Baml in the same assembly. We did this support so that people could build Windows/Pages/UserControls that could be part of your public API, while not requiring that all of the elements/objects that you use must be public.
2 questions related to this:
- if you are using internal types in Xaml, why do you find it useful?
- how critical do you think it is that Silverlight support a similar feature? why?
Rob Relyea 
I want internal types across assemblies too. I dont want to have to expose types publically, and perhaps *document* them because they are public because of some silly rule. If I do the \’right thing\’ with InternalsVisibleTo, it should work perfectly. Today, internal is hobbled in XAML due to it ignoring internal visible to.
grork-
That should have worked. Have you filed a bug via connect? (http://robrelyea.com/wpf/connect will get you to the right place). Thanks for letting us knw.
-Rob
We use (or would like to use) internal types in XAML in order to prevent exposure to third-party code, minimize our attack surface, and also to minimize false positives from the high scrutiny afforded public types by code analysis tools such as FxCop and PREsharp. Looking forward, we\’d like Silverlight to support a similar feature so that we can share UI between our Silverlight and Rich WPF clients.
grork turns out to be working in MSFT, so we got the bug without going through connect. Turns out that InternalsVisibleTo works in the simple case, but runs into problems once we get signing involved. We are not investigating right now, but have it recorded and will get to it.
Chris-
Thanks for the info…
-Rob