Ich stoße in meinen Unit-Tests auf ein ungewöhnliches Problem. Die Klasse, die ich teste, erstellt zur Laufzeit dynamisch eine Abhängigkeitseigenschaft, und der Typ dieser Abhängigkeitseigenschaft kann abhängig von den Umständen variieren. Während ich meine Komponententests schreibe, muss ich die Abhängigkeitseigenschaft mit verschiedenen Typen erstellen, was zu Fehlern führt, weil Sie eine vorhandene Abhängigkeitseigenschaft nicht neu definieren können.
Gibt es also eine Möglichkeit, eine Abhängigkeitseigenschaft entweder zu entfernen oder den Typ einer vorhandenen Abhängigkeitseigenschaft zu ändern?
Danke!
MitOverrideMetadata () können Sie nur einige wenige Dinge wie den Standardwert ändern, was nicht hilfreich ist. Der AppDomain-Ansatz ist eine gute Idee und könnte funktionieren, scheint aber komplizierter zu sein, als ich wirklich eingehend testen wollte.
Ich habe nie eine Möglichkeit gefunden, eine Abhängigkeitseigenschaft aufzuheben, also habe ich meine Komponententests gestochen und sorgfältig reorganisiert, um das Problem zu vermeiden. Ich bekomme ein bisschen weniger Testabdeckung, aber da dieses Problem niemals in einer realen Anwendung auftreten würde und nur während des Komponententests, kann ich damit leben.
Danke für die Hilfe!
Ich hatte gerade gestern ein ähnliches Problem, als ich versuchte, meine eigene DependencyProperty-Erstellungsklasse zu testen. Ich bin auf diese Frage gestoßen und habe festgestellt, dass es keine echte Lösung für die Aufhebung der Registrierung von Abhängigkeitseigenschaften gibt. Also habe ich graben mit Red Gate .NET Reflektor um zu sehen, was ich mir vorstellen konnte.
> Mit Blick auf die Überladungen DependencyProperty.Register schienen alle auf DependencyProperty.RegisterCommon zu zeigen. Diese Methode hat zwei Teile:
Zuerst prüfen Sie, ob die Eigenschaft bereits registriert ist
%Vor%Zweitens, Registrieren der DependencyProperty
%Vor% Beide Teile sind um DependencyProperty.PropertyFromName , eine HashTable, zentriert. Ich habe auch die DependencyProperty.RegisteredPropertyList und ItemStructList<DependencyProperty> bemerkt, aber nicht gesehen, wo sie benutzt wird. Aus Sicherheitsgründen dachte ich, dass ich versuchen würde, das auch zu entfernen.
Also habe ich den folgenden Code gefunden, mit dem ich eine Abhängigkeitseigenschaft "abmelden" konnte.
%Vor%Es hat gut genug funktioniert, dass ich meine Tests ausführen konnte, ohne eine "AlreadyRegistered" -Ausnahme zu erhalten. Es wird jedoch dringend empfohlen, in keinem Produktionscode zu verwenden. Es gibt wahrscheinlich einen Grund dafür, dass MSFT keine formale Methode zur Aufhebung der Registrierung einer Abhängigkeitseigenschaft ausgewählt hat und versucht, dagegen vorzugehen es fragt nur nach Ärger.
Wenn alles andere fehlschlägt, können Sie für jeden Test eine neue Anwendungsdomäne erstellen.
Wenn wir den Namen für ein Label wie folgt registrieren:
%Vor%Wir können den Namen einfach wieder aufheben, indem wir Folgendes verwenden:
%Vor% Ich stand vor einem Szenario, in dem ich ein benutzerdefiniertes Steuerelement erstellt habe, das von Selector erbt, das zwei ItemsSource-Eigenschaften haben soll: HorizontalItemsSource und VerticalItemsSource .
Ich verwende nicht einmal die ItemsControl-Eigenschaft und möchte nicht, dass der Benutzer darauf zugreifen kann.
Also lese ich statenjason's große Antwort , und es gab mir einen großen POV, wie man eine DP entfernt.
Mein Problem war jedoch, dass ich das ItemsSourceProperty member und das ItemsSource als Private Shadows ( private new in C #) deklarierte, konnte es zur Entwurfszeit nicht laden, da MyControlType.ItemsSourceProperty sich auf die beschattete Variable.
Auch wenn ich die oben erwähnte Schleife benutze ( foreach DictionaryEntry usw.), wurde eine Ausnahme ausgelöst, die besagt, dass sich die Sammlung während der Iteration geändert hat.
Daher kam ich zu einem etwas anderen Ansatz, bei dem die DependencyProperty zur Laufzeit hartcodiert referenziert wird und die Sammlung in das Array kopiert wird, so dass sie nicht verändert wird (VB.NET, sorry):
%Vor% Wichtiger Hinweis: Der obige Code ist im gemeinsam genutzten Konstruktor des benutzerdefinierten Steuerelements enthalten, und ich muss nicht überprüfen, ob er registriert ist, da ich eine Unterklasse von Selector kenne Stellt das ItemsSource dp.
Es gab ein Problem mit einem ContentPresenter mit verschiedenen Datamplates, von denen einer eine DependencyProperty mit einem PropertyChangedCallback hatte Wenn der Inhalt von ContentPresenter in ein anderes DataTemplate geändert wurde, blieb der Rückruf bestehen.
Im Ereignis UserControls Unloaded habe ich Folgendes aufgerufen:
%Vor%Das hat für mich funktioniert
Tags und Links wpf .net dependency-properties