XmlnsDefinition для рекурсивных пространств имен - PullRequest
1 голос
/ 21 января 2010

У меня есть проект, который структурирован с использованием пространства имен .net с именем ViewParts. С другой стороны, он состоит из множества разных подпапок с пользовательскими элементами управления wpf.

Я добавил атрибут XmlnsDefinition в мой файл AssemblyInfo.cs, чтобы сопоставить это пространство имен .net с uri для использования в других файлах window / usercontrol. Но мне бы очень хотелось, чтобы атрибут работал в «рекурсивном режиме». То есть: я хочу, чтобы он включал все подпапки ниже указанного пространства имен .net. В противном случае мне придется заходить в файл AssemblyInfo.cs и добавлять строку каждый раз, когда я добавляю новый viewpart / usercontrol, и это просто еще один шаг, который будет забыт ...

Возможно ли это как-нибудь?

1 Ответ

2 голосов
/ 21 января 2010

Все возможно.

В этом случае, однако, это не особенно легко. XmlnsDefinition атрибуты читаются непосредственно анализатором XAML, и он не имеет рекурсивной функции пространства имен. Если у вас на самом деле нет атрибутов XmlnsDefinition в вашей сборке, синтаксический анализатор XAML не добавит их в свою таблицу и вы не получите требуемые отображения.

Изменение синтаксического анализатора XAML не очень хорошая идея, потому что внутренности, с которыми вам придется работать, могут измениться. К счастью, автоматическое добавление XmlnsDefinitions не так сложно.

Я дам вам три способа изменить процесс сборки, чтобы автоматизировать это. В каждом случае вы начнете с перемещения ваших XmlnsDefinition атрибутов, которые вы хотите сделать рекурсивными, из AssemblyInfo.cs в другой файл, который будет перезаписан вашим шагом сборки. Это возможно, потому что атрибуты [assembly:] можно найти в любом файле. Независимо от того, где они находятся, компилятор C # добавляет их в то же место в результирующей сборке.

Теперь, когда ваш файл отдельный, вот три подхода к его автоматической перестройке каждый раз, когда вы нажимаете F5 или Ctrl-Shift-B или что-то еще:

  1. Добавьте событие после сборки, которое загружает .dll, использует отражение для перечисления типов и создает список пространств имен с нужным префиксом. Запишите это в свой файл «XmlnsDefinitions.cs» (также необходимо удалить бит только для чтения), чтобы при следующей компиляции он имел правильные определения. Недостатки: плохое взаимодействие с системой контроля версий и для получения правильного вывода необходимо дважды скомпилировать.

  2. Добавьте задачу сборки (ссылка Microsoft.Build.Framework и подкласс Microsoft.Build.Framework.Task), которая создает файл "XmlDefinitions.cs" как сгенерированный файл, анализируя исходный код. Включите вызов этой задачи в свой файл .csproj (или в отдельный файл .targets, включенный в ваш файл .csproj). Недостатки: больше работы, чем # 1, написание исходного синтаксического анализатора для пространств имен, осложненного возможностью вложенных пространств имен.

  3. Добавьте задачу сборки, которая создает файл "XmlnsDefinitions.cs", отражая вывод .dll. Затем добавьте пользовательский файл .targets, который компилирует ваше приложение без XmlnsDefinitions.cs, затем создает файл XmlnsDefintions.cs, а затем снова компилируется. Недостатки: сложный процесс сборки, сложные изменения msbuild, показ из-за двойной компиляции.

...