4. [WPF] Undefined CLR namespace (bzw. schlechter Designer?)

[WPF] Undefined CLR namespace (bzw. schlechter Designer?)

  • A

    Ich habe im xaml ein Fenster definiert, und wollte mit dem xmlns-Tag einen eigenen Namensraum aus der gleichen Assembly einbinden. Der Tag-Inhalt wurde mir sogar von der IDE so vorgeschlagen (Namensraum wurde vom Intellisense gefunden). Ich bekomme aber dennoch einen Fehler gemeldet:

    Fehler: Undefined CLR namespace. The 'clr-namespace' URI refers to a namespace 'xyz.Base.UI.UserControl' that is not included in the assembly

    <Window x:Class="xyz.Base.UI.EditWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:controls="clr-namespace:xyz.Base.UserControl"
    Height="600" Width="800" MinHeight="600" MinWidth="800">
...

    (Anmerkung den Fehler konnte ich schon unter Visual Studio 2005 mit .Net 3.0 als auch Visual Studio 2008 mit .Net 3.5 hinbekommen)

    Was nun mein Verständnis von XAML wiederspricht ist, das wenn ich nun dieses "Defekte Fenster" entferne und nochmal mit gleichen XAML-Code einfüge, dieser Fehler behoben ist.

    Zudem ist es auch schön wenn man nachträglich den Namensraum eines Fensters ändern will. Man gibt dann den Namensraum im "x:Class"-Tag richtig an, und passt auch die zugehörige cs-Datei entsprechend an, nur wird nicht der Compilergenerierte Code aus der XAML wieder generiert (Sprich: auch hier, entfernen und neuanlegen).

    Auch schön ist, wenn man irgendwann im XAML einen Fehler gemacht hat, und diesen Korrigiert man manchmal weiterhin den Code als Defekt gemeldet bekommt (Auch hier: Neuanlage mit exakt gleichen XAML-Code stellt kein Problem dar).

    Hat jemand einen besseren Workaround als das Neuanlegen wenn XAML mit einer Änderung nicht klarkommt?

    0
  • S

    warten bis das erste service pack kommt 😉

    Ich habe das Problem noch nicht gehabt, vergleiche doch mal alle Dateien das Projekts auf Änderungen, wenn der Fehler kommt.

    0
  • ?

    Der Vollständigkeit halber (auch wenn der Beitrag schon alt ist), weil das Problem offensichtlich auch das VS2010 betrifft:

    Es kann mit der Plattformeinstellung zusammen hängen. In meinen Fällen war es oft so, dass VS für den Designer nur in den Pfaden der Standardplattform nachgeschaut hat.
    Da das bei mir eigentlich immer x86 bzw. Any CPU war, aber nie x64, kam regelmäßig dieser Fehler. Geholfen hat manchmal, die Einträge im csproj-File anzupassen (das heißt, bei den Projekteinstellungen als Plattform das x86 durch x64 auszutauschen)...

    Vielleicht hilft das manchem.

    0
  • Z

    asc schrieb:

    Hat jemand einen besseren Workaround als das Neuanlegen wenn XAML mit einer Änderung nicht klarkommt?

    Versuchst mit Clean & Build.

    0
  • A

    Zeus schrieb:

    asc schrieb:

    Hat jemand einen besseren Workaround als das Neuanlegen wenn XAML mit einer Änderung nicht klarkommt?

    Versuchst mit Clean & Build.

    Auch wenn der Vorgang sehr alt ist: Hatte damals nicht funktioniert.

    0
Anmelden zum Antworten