Laden...

CustomControl wird in XAML nach geändertem AssemblyName nicht gefunden

Erstellt von Palladin007 vor 2 Jahren Letzter Beitrag vor 2 Jahren 518 Views
Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 2 Jahren
CustomControl wird in XAML nach geändertem AssemblyName nicht gefunden

Hi,

ich arbeite mit WPF, .NET 5 und VS2022 Preview.
Außerdem habe ich eine Directory.Build.props, in der ich Firmen- und Projekt-Name vor Namespace und Assembly hänge.

Die Directory.Build.props enthält also sowas:


<PropertyGroup Condition="!$(MSBuildProjectName.StartsWith('$(ApplicationName).'))">
	<RootNamespace>$(ApplicationName).$(MSBuildProjectName)</RootNamespace>
	<AssemblyName>$(ApplicationName).$(MSBuildProjectName)</AssemblyName>
</PropertyGroup>

$(ApplicationName) ist dann z.B. "Firma.Produkt".

Im Startprojekt habe ich ein CustomControl vom Template hinzugefügt.
Es wurde also ein CustomControl.cs und eine Generic.xaml erstellt, in der dann der Style für das Control steht.

Die XMLNS-Definition:


xmlns:local="clr-namespace:Firma.Produkt.MyApp"

Das Problem ist:
Mit der AssemblyName-Zeile in der Directory.Build.props funktioniert es nicht.
Nehme ich die AssemblyName-Zeile aus der Directory.Build.props raus, funktioniert es.

Folgender Fehler:

Fehlermeldung:
The name "CustomControl1" does not exist in the namespace "clr-namespace:Firma.Produkt.MyApp".
The name "CustomControl1" does not exist in the namespace "clr-namespace:Firma.Produkt.MyApp".
Cannot find the type 'local:CustomControl1'. Note that type names are case sensitive.

Die Namespaces habe ich gefühlt 100 Mal kontrolliert, die stimmen also.
Namespace und AssemblyName sind - wie man oben sieht - auch identisch.
Der XAML-Editor erkennt mein Control auch, zumindest bietet er es mir in der Intellisense an.

Ist das ein Bug?
Habe ich was übersehen?

Im Anhang ist ein minimalistisches Beispiel-Projekt, einfach die AssemblyName-Zeile in der csproj ein- bzw. auskommentieren.

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 2 Jahren

Ok, ich hab eine Lösung.

Eine global.json mit folgendem Inhalt neben die sln-Datei:


{
  "sdk": {
    "allowPrerelease": false
  }
}

Im Projekt ist .NET 5 eingestellt, aber den Compiler nimmt er scheinbar immer von der neusten Version und das ist bei mir .NET 6 RC2.

If you are in Visual Studio, it uses the prerelease status requested. That is, if you're using a Preview version of Visual Studio or you set the Use previews of the .NET Core SDK option (under Tools > Options > Environment > Preview Features), the default value is true; otherwise, false.

Zitat von hier: global.json overview - .NET CLI

Also bin ich wohl selber schuld 😠

16.807 Beiträge seit 2008
vor 2 Jahren

Also ja, das ist wirklich so; es ist empfohlen das genaue SDK in der global.json zu konfigurieren.


{
    "sdk": {
        "version": "5.0.400"
    }
}

Erspart auch viel Ärger mit komischen Seiteneffekten auf CI/CD Servern 🙂

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 2 Jahren

Habe ich mir auch schon überlegt.
Aber was für Auswirkungen hat es, wenn die konkrete Version nicht installiert ist?

Und ich hab aktuell bei mir 5.0.401 und 5.0.402 installiert, keine 5.0.400.
Bei meinem kleinen Text hat's funktioniert, aber einen Beigeschmack hat's trotzdem irgendwie.
Schöner wäre natürlich, wenn es Wildcards unterstützen würde 😠

16.807 Beiträge seit 2008
vor 2 Jahren

Aber was für Auswirkungen hat es, wenn die konkrete Version nicht installiert ist?

Dann knallt es -> fail fast.

Schöner wäre natürlich, wenn es Wildcards unterstützen würde 😠

Siehe https://github.com/dotnet/runtime/issues/2541

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 2 Jahren

Dann knallt es -> fail fast.

Bei meinem Test lief es.
Vielleicht liegt das aber auch einfach daran, dass der Unterschied ziemlich klein ist.
Wenn z.B. nur .NET 6 installiert ist, dann darf es ruhig knallen 😁

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 2 Jahren

Der Fehler lag nicht an der PreRelease sondern generell an .NET 6 und wurde mit dem Release nicht gefixt.
Das Problem ist die "IncludePackageReferencesDuringMarkupCompilation"-Property, ihr Default-Wert wurde zwischen .NET 5 und 6 von false auf true geändert.
Man kann das Problem also "lösen", indem man in der Projekt-Datei folgendes in eine PropertyGroup schreibt:


<IncludePackageReferencesDuringMarkupCompilation>false</IncludePackageReferencesDuringMarkupCompilation>