Jak zmusić WPF do używania identyfikatorów URI zasobów, które używają silnej nazwy zespołu? Argh!

Question

O.k, to jest naprawdę irytujące, wcześniej zauważyłem, że kod generowany przez WPF do ładowania zasobów XAML nie wydaje się używać silnych nazw i dlatego może być problematyczny w scenariuszach, w których trzeba wspierać równoległe wersje złożeń WPF.

Okazało się, że tak jest, i teraz powoduje to problemy - mam system wtyczek, który ma obsługiwać instalację wtyczek różniących się tylko numerem wersji (wersją) . To oczywiście może być wspierane przez .NET, ponieważ assemblie są określane, aby mieć różne tożsamości, nawet jeśli mają tę samą nazwę pliku DLL, pod warunkiem, że są silnie nazwane i mają inny publiczny/prywatny klucz LUB mają inny numer wersji zespołu.

Teraz, jeśli spojrzymy na kod wygenerowany dla okien i usercontrols przez visual studio, widzimy w pliku generowanego automatycznie następuje:

/// <summary> 
/// InitializeComponent 
/// </summary> 
[System.Diagnostics.DebuggerNonUserCodeAttribute()] 
public void InitializeComponent() { 
    if (_contentLoaded) { 
     return; 
    } 
    _contentLoaded = true; 
    System.Uri resourceLocater = new System.Uri("/Sensormatic.AMK1000.Panel;component/views/servicepanelui.xaml", System.UriKind.Relative); 

    #line 1 "..\..\..\Views\ServicePanelUI.xaml" 
    System.Windows.Application.LoadComponent(this, resourceLocater); 

    #line default 
    #line hidden 
} 

Zawiadomienie linii, gdzie lokalizator zasobów jest tworzony - go używa względnego identyfikatora URI, który nie określa silnej nazwy lub wersji zestawu, który zawiera zasób xaml.

Pomyślałem, że może LoadComponent sprawdzi tożsamość zespołu wywołującego i użyje jego klucza publicznego i szczegółów wersji lub może sprawdzi tożsamość zespołu, który zawiera typ dla tego parametru.

Wygląda na to, że tak nie jest - jeśli masz dwa zespoły z różnymi numerami wersji (ale taką samą nazwę pliku), możesz uzyskać wyjątek IOException z komunikatem "Nie można zlokalizować zasobu X" (dla powyższego przykładu "Nie można zlokalizować zasobu "views/servicepanelui.xaml."

Co gorsza, jestem pewny, że oznacza to również, że złożenia o tej samej nazwie pliku, ale innym kluczu publicznym/prywatnym, tj. od różnych wydawców, również spowodują ten błąd

Więc, czy ktoś wie jak się z tym obejść? Jak sprawić, by nazwa WPF była zgodna z nazwą?

Uwaga, o ile mi wiadomo, jest to błąd WPF. Nie należy używać izolacji Appdomain, aby tego uniknąć.

Answer 1

Zgadzam się, że jest to prawdopodobnie błąd, a przynajmniej niedobór oprzyrządowania XAML. Być może powinieneś zgłosić to na Connect.

nie próbowałem, ale oto kilka potencjalnych obejścia:

1. wstrzyknąć etap pre-build do automatycznego modyfikowania plików .g.cs używać pack URIs określających pełną informację zmontują (AssemblyShortName [; Version] [; PublicKey]; komponent/Ścieżka)
2. Dołączyć do AppDomain.AssemblyResolve pomóc CLR znaleźć odpowiedni montaż

Answer 2

doznałem tego samego PROBL em i może to być możliwe rozwiązanie

za każdym razem, gdy kontrola jest tworzona za pomocą strony .xaml, na załączonym.konstruktor plik cs przed InitializeComponent() połączenia, należy dodać następujące wiersze:

 
contentLoaded = true; 
var assemblyName = GetType().Assembly.GetName(); 
System.Windows.Application.LoadComponent(GetType(), new Uri(
       string.Format("/{0};v{1};component{2}/{3}.xaml", 
       assemblyName.Name, 
       assemblyName.Version, 
       [[[namespace]]], 
       type.Name 
       ), UriKind.Relative)) 

gdzie jako [[[nazw]]] wprowadzić pełną nazw klasy, z wyjątkiem domyślnej przestrzeni nazw projektu Visual Studio

(Uwaga: istnieje Otwórz zaznaczone na connect https://connect.microsoft.com/VisualStudio/feedback/details/668914/xaml-generated-code-uses-resource-uri-without-assembly-strong-name)

Answer 3

można ustawić następujące w pliku projektu zmianę URI w wygenerowanym kodzie:

<PropertyGroup> 
    <AssemblyVersion>1.0.0.0</AssemblyVersion> 
    <AssemblyPublicKeyToken>[YOUR_PUBLIC_KEY_TOKEN]</AssemblyPublicKeyToken> 
</PropertyGroup> 

Answer 4

Zmagam się z tym w VS2012. Nie mogłem znaleźć rozwiązania Riccardo do pracy w tym środowisku. Ten wariant jego kodem ...

_contentLoaded = true; 
var assemblyName = GetType().Assembly.GetName(); 
Application.LoadComponent(this, new Uri(String.Format("/{0};v{1};component/CustomersFrame.xaml", assemblyName.Name, assemblyName.Version), UriKind.Relative)); 

... nie rozwiąże problemu „nie może zlokalizować źródło”, ale potem hit następujący błąd nieco dalej wzdłuż w elemencie dziecka: „Nie można zarejestrować nazwie obiektu. Nie można zarejestrować zduplikowanej nazwy "szukaj" w tym zakresie. "

Rozwiązanie Aarona Martena działa dla mnie. Niestety nie mogę komentować ani przegłosować, ale nie mam przedstawiciela.

Answer 5

Możesz również przekazać parametr/p: AssemblyVersion = $ version do procesu msbuild, jeśli kompilacje są zautomatyzowane.

Answer 6

Ten kod, oparty na odpowiedzi Riccardo, pracował dla mnie w VS2010.

Najpierw zdefiniowałem metodę ładującą, którą mogę wywołać z mojego konstruktora XAML.

namespace Utility 
{ 
    public class Utility 
    { 
     public static void LoadXaml(Object obj) 
     { 
      var type = obj.GetType(); 
      var assemblyName = type.Assembly.GetName(); 
      var uristring = string.Format("/{0};v{1};component/{2}.xaml", 
       assemblyName.Name, 
       assemblyName.Version, 
       type.Name); 
      var uri = new Uri(uristring, UriKind.Relative); 
      System.Windows.Application.LoadComponent(obj, uri); 
     } 
    } 
} 

Następnie w konstruktorze dla każdej kontroli XAML, Wymieniłem InitializeComponent() z:

 _contentLoaded = true; 
     Utility.Utility.LoadXaml(this); 
     InitializeComponent(); 

Zauważyłem, że niektórzy z moich wiązań RelativeSource przestał działać, ale udało mi się obejść .