我有一个名为ViewParts的.NET命名空间结构的项目。另一方面，这包含许多不同的子文件夹，其中包含wpf usercontrols。用于递归命名空间的XmlnsDefinition
我已将XmlnsDefinition属性添加到我的AssemblyInfo.cs文件中，以将该.net命名空间映射到其他窗口/用户控件文件中使用的uri。但我真的很喜欢这个属性在“递归模式”下工作。那就是：我希望它包含我指定的.net命名空间下的所有子文件夹。 否则我将不得不进入AssemblyInfo.cs文件，并添加一行每次我添加一个新的ViewPart时/用户控件，这是刚刚另一个步说，将-GET-遗忘...
这是可能以任何方式？
任何事情都有可能。
在这种情况下，它并不是特别容易。 XmlnsDefinition属性由XAML解析器直接读取，并且没有递归名称空间功能。除非在程序集中实际上具有XmlnsDefinition属性，否则XAML解析器不会将它们添加到其表中，并且不会获得所需的映射。
修改XAML解析器不是一个好主意，因为您需要解决的内部问题可能会发生变化。幸运的是，自动添加XmlnsDefinitions并不困难。
我会给你三种方法来修改你的构建过程以实现自动化。在每一种情况下，您都会首先将您想要递归的XmlnsDefinition属性从AssemblyInfo.cs中移出，然后移入另一个由构建步骤重写的文件。这是可能的，因为[assembly：]属性可以在任何文件中找到。无论它们在哪里找到，C＃编译器都会将它们添加到生成的程序集中的相同位置。
现在你的文件是一个单独的一个，这里有三种方法每次按F5键或Ctrl-Shift-B键或任何时间自动重建它：
添加一个生成后事件加载.dll，使用反射枚举类型，并用所需的前缀构建名称空间列表。把它写到你的“XmlnsDefinitions.cs”文件中（也必须删除只读位），所以下次编译它时会有正确的定义。缺点：与源代码管理的交互不良&必须编译两次以获得正确的输出。
添加其通过解析源代码构建“XmlDefinitions.cs”的文件作为生成的文件的生成任务（参考Microsoft.Build.Framework和亚类Microsoft.Build.Framework.Task）。在您的.csproj文件中包含对此任务的调用（或者包含在.csproj中的单独的.targets文件中）。缺点：比＃1更多的工作，为命名空间编写源代码解析器，使嵌套命名空间的可能性复杂化。
通过反映.dll输出添加构建“XmlnsDefinitions.cs”文件的构建任务。然后添加一个自定义的.targets文件，该文件在没有XmlnsDefinitions.cs的情况下编译您的应用程序，然后构建XmlnsDefintions.cs，然后再次编译。缺点：复杂的构建过程，复杂的msbuild变化，因编译两次而显示。