Question

i have a project that is structured with a .net namespace called ViewParts. This, on the other hand, consists of many different subfolder with wpf usercontrols in them.

I have added an XmlnsDefinition attribute to my AssemblyInfo.cs file to map that .net namespace to a uri for use in other window/usercontrol files. But i would really love to have the attribute work in “recursive-mode”. That is: i want it to include all subfolders below the .net namespace that i specify.
Otherwise i will have to go into the AssemblyInfo.cs file and add a line everytime i add a new viewpart/usercontrol and that is just-another-step-that-will-get-forgotten…

Is this possible in any way?

Answer 1

Anything is possible.

In this case, though, it is not particularly easy. XmlnsDefinition attributes are read directly by the XAML parser, and it has no recursive namespace feature. Unless you actually have the XmlnsDefinition attributes on your assembly the XAML parser will not add them to its table and you will not get the mappings you want.

Modifying the XAML parser is not a good idea because the internals you’d need to muck with are likely to change. Fortunately adding XmlnsDefinitions autoamtically is not that difficult.

I’ll give you three ways to modify your build process to automate this. In each case you will start by moving your XmlnsDefinition attributes that you want to be recursive out of AssemblyInfo.cs and into another file that is rewritten by your build step. This is possible because [assembly:] attributes can be found in any file. No matter where they are found the C# compiler adds them to the same place in the resulting assembly.

Now that your file is a separate one, here are the three approaches to rebuilding it automatically every time you hit F5 or Ctrl-Shift-B or whatever:

1. Add a post-build event that loads the .dll, uses reflection to enumerate the types, and builds a list of namespaces with the desired prefix. Write this to your “XmlnsDefinitions.cs” file (must also remove read-only bit) so the next time you compile it will have the right definitions. Disadvantages: poor interaction with source control & must compile twice to get correct output.

2. Add a build task (reference Microsoft.Build.Framework and subclass Microsoft.Build.Framework.Task) that constructs the “XmlDefinitions.cs” file as a generated file by parsing the source code. Include a call to this task in your .csproj file (or in a separate .targets file that is included from your .csproj). Disadvantages: More work than #1, writing source parser for namespaces complicated by possibility of nested namespaces.

3. Add a build task that constructs the “XmlnsDefinitions.cs” file by reflecting on the .dll output. Then add a custom .targets file that compiles your app without XmlnsDefinitions.cs, then builds XmlnsDefintions.cs, then compiles again. Disadvantages: Complex build process, complex msbuild changes, show because of compiling twice.