Make XmlnsDefinitionAttribute Public #2691
Comments
This would have a lot of great uses including for Frameworks, Toolkits, really any library built around Forms |
Interestingly it was originally public, and then changed to internal: |
It is internal because the parser only looks for those attributes in known assemblies. Making it public won't make it work, it requires some changes. Not impossible, not even hard... |
Ah, that makes sense and also explains this comment!
Would this be something that y'all would entertain a PR on? |
PR is welcome should be fixed in the XamlParser and in
|
Now that I think about it, it was made internal, and only looking into known assemblies, so we're sure it doesn't collide with UWP's (and now WPF's) XmlnsDefinitionAttribute. I don't think it's a problem, as we define our own XmlnsDefinitionAttribute (not part of |
Well I've made good progress but hit a stumbling block in This gets called during the XAML build process to generate the code-behind .g.cs files. The problem is that at this point the assembly doesn't exist yet, so I can't use reflection to find the assemblies referenced in order to look for I'm gonna check out the .NET Reference Source to see how WPF handles this but would love any suggestions. Thanks! |
@peter0302 oh, yes, there is that too... lemme think about it |
@peter0302 iirc, my conclusion at the time was that XamlG would need to be rebased to work on top of Roslyn to allow that. I have an experimental branch around, doing Xaml-related work while having all the Roslyn context. I'll see if I can do something with it... |
I'm making some progress on the MSBuild Task front. I finally figured out how to pass the Anyway, now that I have those reference paths I can look for the The only thing that bothers me is that there'll now be three different places where it'll be checking for the NS definitions: |
Ok it's looking good! I have custom namespaces working with My work is here if anyone wants to take a look and comment first: https://github.com/peter0302/Xamarin.Forms/tree/2691-xmlnsdefinitionattribute-public @StephaneDelcroix did you need to mark this proposal as accepted first? |
no, that's fine |
@StephaneDelcroix just a quick update. Was finally able to test successfully in VS for Mac yesterday with iOS and MacOS platforms and that's working fine. Just cleaning up the commits in my own fork and should have a PR to you today or tomorrow. All XAML unit tests are passing (and I added three directed to this issue) but not all UITests are, and I haven't been able to run the Windows UI unit tests at all. This is true in master even without my changes. Is this normal/expected? It looks like some of them are looking for network locations that don't exist so I'm wondering if they're out of date or just need to be run on your internal Network? Also I don't think I can make a meaningful UI unit test for this because - correct me if I'm wrong - it looks like they all build their UI in C# code and not in XAML so there wouldn't be any point. I did add the issue to the control gallery though so it can be looked up and a demonstration viewed when you run it as an app. I also added XAML unit tests like I mentioned that test XamlG, XamlC, and XamlParser, respectively. |
this doesn't require uitests. it can be all unittested |
* Make XmlnsDefinitionAttribute public. Change XamlC, XamlG, and XamlParser to search for all referenced/available assemblies for attribute and referenced types. Add XAML unit tests and control gallery entry. * change ns for xmlnsdefattribute - fixes #2691
Summary
Make
XmlnsDefinitionAttribute
PublicAPI Changes
Change
XmlnsDefinitionAttribute
accessibility topublic
.Intended Use Case
Control library authors would be able to use their own custom namespace schema definitions (e.g.
http://mycompany.com/xaml
rather than having to specify the exact assembly name and CLR namespace in thexmlns
definitions. It would permit using a single namespace prefix for all custom controls in a library package even if the controls are in different assemblies / namespaces.The text was updated successfully, but these errors were encountered: