2011-07-29 20 views
9

Wyobraź sobie, że pracujesz nad projektem .Net 4.0, który składa się z setek zestawów, z których każdy ma własny plik zasobów (.resx) do lokalizacji. Zlokalizowane ciągi są dostępne z C# przez klas generowane automatycznie z ResXFileCodeGenerator (który tworzy „ResourceFile.Designer.cs” pliku): string test = ResourceFile.TestString;Jak dokonać dziedziczenia plików zasobów (Resx)

Każdy zespół ma zlokalizowane ciągi, które są przede wszystkim do niego, ale nie są ciągi, które są wspólne dla wszystkich zgromadzeń. Mówisz sobie, że byłoby miło mieć te "wspólne ciągi" w "macierzystym" pliku zasobów, na którym kod zostałby przywrócony, jeśli klucz zasobów nie jest dostępny w "lokalnym" pliku zasobów. Potem mówisz: "Hej, dziedziczenie może tu działać". I rzeczywiście, robi się coś takiego w automatycznie generowanym pliku projektanta, działa: internal class ResourceFile : ParentResourceFile Oznacza to, że ciągi nie zdefiniowane w ResourceFile, ale zdefiniowane w ParentResourceFile, nadal można uzyskać dostęp z ResourceFile.StringInParentFile.

Ale coś w kłopotach nagłówka pliku projektanta ty: „zmian do tego pliku może spowodować nieprawidłowe zachowanie i zostaną utracone, jeśli kod jest regenerowany.” Plus wiesz grając w automatycznie generowanych plików projektantów jest źle widziane. Więc chodź tu i pytasz:

  • Kiedy ResXFileCodeGenerator wygenerować/zregenerować projektant klasę?
  • Czy istnieje sposób wyłączenia automatycznego generowania?
  • Czy będziemy mieć , aby zrezygnować z zalet narzędzia ResXFileCodeGenerator i wdrożyć naszą własną obsługę ResourceManager ?

I mówisz "dziękuję".

Odpowiedz

5

Po zbadaniu problemu przez jakiś czas, zdecydowałem się na obejście: nie dziedziczenie nie dotyczy samych plików zasobów, ale klasy, które muszą uzyskać dostęp do zasobów "nadrzędnych".

Wystarczy tylko mieć klasę bazową, którego projekt zawiera „master” plik zasobów i ustaw właściwość CustomTool tego pliku zasobów do PublicResXFileCodeGenerator (część „publiczny” jest istotne, gdyż utworzyć klasę public, jak w przeciwieństwie do wersji internal). Jednym z ograniczeń jest to, że PublicResXFileCodeGenerator jest dostępny tylko począwszy od VS2008 (ten CodeProject article mógłby być pomocny).

Następnie w klasach, które potrzebują dostępu do „master” zasobów, po prostu dziedziczą z klasy bazowej i dostęp do zasobów tak:

public class ChildClass : BaseClass 
{ 
    string test = BaseClass.BaseResourceFile.TestString; // a common resource 
    string localResource = ResourceFile.OtherString;  // a local resource 
} 

Wadą tego rozwiązania jest to, że trzeba wyraźnie odwoływać BaseResourceFile, aby uzyskać dostęp do zasobów tam zdefiniowanych; nie ma powrotu do klasy nadrzędnej, jak gdyby gdyby dziedziczenie odbywało się bezpośrednio między klasami zasobów.

A dla potomności, będę odpowiadać na moje własne pytania:

  • Kiedy ResXFileCodeGenerator wygenerować/zregenerować projektant klasę?

    Zawsze, gdy zasób jest dodawany/usuwany/modyfikowany.

  • Czy istnieje sposób wyłączenia automatycznego generowania?

    Nie. W każdym razie narzędzie "generatora kodu" bez automatycznego generowania byłoby bezużyteczne, nie sądzisz?

  • Czy będziemy musieli zrezygnować z zalet narzędzia ResXFileCodeGenerator i wdrożyć naszą własną obsługę środowiska ResourceManager za pomocą ?

    Nie, patrz wyżej odpowiedź.

również rozważyć wdrożenie rozwiązania przy użyciu „połączony” pliki (w oknie dialogowym „Dodaj istniejący element”, używając opcji „Dodaj link”), gdzie plik zasobów jeden rodzic byłby powiązany ze wszystkimi naszymi zespołami, ale odkąd nasze zgromadzenia już odziedziczyły klasę podstawową, wydawało się, że lepiej pójść na dziedziczenie.

Nie czuję się dobrze przyjmując własną odpowiedź, więc jeśli ktoś zaproponuje lepsze rozwiązanie lub ulepszenia mojego rozwiązania, chętnie to zaakceptuję. To znaczy, jeśli komukolwiek zależy.

+0

to nie działa dla mnie ... Jak to się stało, że można było wywołać "BaseClass.BaseResourceFile.TestString"? – Denis

Powiązane problemy