MC3074 - typ nie istnieje w "clr-namespace ..."

Question

Mam problemy z odwoływaniem się do klas w xaml z innych złożeń.

W tym samym rozwiązaniu mam dwa projekty. Jeden o nazwie Controls (do przechowywania kontroli użytkowników) i jeden o nazwie DataBinding (przechowuje konwertery/reguły sprawdzania poprawności). W kontroli, im próbą odniesienia reguła walidacji w XAML:

<Binding.ValidationRules> 
    <databind:Validators.FileExistsRule /> 
</Binding.ValidationRules> 

Mój projekt odwołuje się projekt zawierający moje zajęcia. Ive dodał tę deklarację na szczycie mojej Control.xaml:

xmlns:databind="clr-namespace:GuiParts.DataBinding;assembly=DataBinding" 

Jednak, kiedy skompilować, pojawia się błąd:

The tag 'Validators.FileExistsRule' does not exist in XML namespace 'clr-namespace:GuiParts.DataBinding;assembly=DataBinding'. 

Klasa pewno istnieje, mogę zadzwonić go w kodzie z tyłu bez żadnych problemów, ale nie za pośrednictwem xaml. Jeśli przeniesię klasę do tego samego projektu, znowu nie mam żadnych problemów. Widziałem inne pytania na temat tutaj, i próbowałem następujące:

1. czyszczenia i przebudowa wszystkich istotnych projektów
2. zapewnienie wszystkim projekty są skierowane do tej samej wersji .NET (4,0), aby zobaczyć pełny profil
3. Wyjmowanie definicja "złożenia" od końca definicji przestrzeni nazw.

Żadne z powyższych nie zadziałało. Wszelkie sugestie co do tego, gdzie idę źle?

EDIT

Moja FileExists Validator:

namespace GuiParts.DataBinding.Validators 
{ 
    /// <summary> 
    /// Validates that the file with the specified name exists 
    /// </summary> 
    public class FileExistsRule : ValidationRule 
    { 
     public override ValidationResult Validate(object value, CultureInfo cultureInfo) 
     { 
     ValidationResult res = null; 
     res = (! File.Exists((string)value)) 
        ? new ValidationResult(false, "File does not exist") 
        : new ValidationResult(true, null); 
     return res; 
     } 
    } 
} 

mogę nazwać następujące w kodzie tyłu bez żadnych błędów:

new GuiParts.DataBinding.Validators.FileExistsRule(); 

więc ive got my nazw itp poprawne.

Answer 1

Spróbuj tego:

xmlns:databind="clr-namespace:GuiParts.DataBinding.Validators;assembly=DataBinding" 

<Binding.ValidationRules>  
    <databind:FileExistsRule />  
</Binding.ValidationRules> 

Answer 2

1. Czy twoja klasa w twoim docelowym zgromadzeniu jest publiczna?
2. Czy pole w walidatorach jest publiczne?
3. Czy twoja przestrzeń nazw Czy GuiParts.DataBinding jest poprawna?

Answer 3

Chociaż nie jestem pewien, co problem masz jest, można alternatywnie stworzenie przyjaznego definicję przestrzeni nazw dla swoich montażowych i nazw CLR. W rzeczywistości używam tej techniki do grupowania różnych przestrzeni nazw w jedną przestrzeń nazw XML ... Robisz to używając XmlnsPrefixAttribute i XmlnsDefinitionAttribute s.

Na przykład:

[assembly: XmlnsPrefix("http://my.xml.namespace.com/", "databind")] 
[assembly: XmlnsDefinition("http://my.xml.namespace.com/", 
    "GuiParts.DataBinding")] 
[assembly: XmlnsDefinition("http://my.xml.namespace.com/", 
    "GuiParts.DataBinding.Validators")] 

Potem, gdy chcesz odwołać Przestrzenie nazw w XML w XAML po prostu zrobić:

xmlns:databind="http://my.xml.namespace.com/" 

---

Uwaga, używam ReSharper, ale jestem oczywiście działa to również w Visual Studio. Jeśli nie wpisujesz importu xmlns i nie próbujesz użyć obiektu w przestrzeni nazw, to po przejściu do niego automatycznie użyjesz bardziej przyjaznego nazwanego obszaru nazw z określonym przedrostkiem. Ponadto jest to naprawdę miłe i pomaga uniknąć relacji 1: 1 między przestrzeniami nazw XML i przestrzeniami nazw Clr, ponieważ można odwzorować wiele przestrzeni nazw Clr w pojedynczą przestrzeń nazw xml.

Ponownie, nie jestem pewien, jaki jest konkretny problem, ale prawdopodobnie to naprawi i będzie lepszy niż użycie przestrzeni nazw Clr i informacji o złożeniu. Po prostu wymyśl coś unikatowego, aby uniknąć kolizji xmlns lub powrócić do ustawienia nazw Clr/Assembly.

---

Aha, i ostatnia sprawa ... jeśli chcesz wykorzystać wersjonowanie w swoim systemie nazw xml nazewnictwa (które powinny), nie martw się o siebie w blokowania dla wstecznej kompatybilności. Zawsze możesz wykorzystać kod XmlnsCompatibleWithAttribute, aby upewnić się, że kod korzystający ze starej przyjaznej przestrzeni nazw nie zostanie zerwany, jeśli kiedykolwiek zaktualizujesz swoje zewnętrzne zestawy do odwzorowania na nowszy obszar nazw xml.

Na przykład, jeśli pierwotnie miał pan montaż wskazując nazw 2012 roku, następnie włącza go do 2013 nazw, ponieważ zaktualizowane zespół ...

// Previous Assembly version 
//[assembly: XmlnsDefinition("http://schemas.xyzcorp.com/wpf/2012", 
// "Xyz.Databinding")] 

[assembly: XmlnsCompatibleWith("http://schemas.xyzcorp.com/wpf/2012", 
    "http://schemas.xyzcorp.com/wpf/2013")] 
[assembly: XmlnsDefinition("http://schemas.xyzcorp.com/wpf/2013", 
    "Xyz.Databinding")]