Probleme mit dem DeploymentItem-Attribut

94

Ich pflege derzeit ein "altes" System, das in C # .net geschrieben ist, entferne einige veraltete Funktionen und führe einige Umgestaltungen durch. Gott sei Dank hat der Vorgänger einige Unit-Tests (MSTests) geschrieben. Ich bin ziemlich zufrieden mit JUnit-Tests, habe aber noch nicht viel mit MSTests gemacht.

Die Testmethoden haben ein DeploymentItemAttribut, das eine Textdatei angibt, die von der zu testenden Geschäftslogikmethode analysiert wird, und eine zweite, DeploymentItemin der nur ein Pfad angegeben wurde, der eine Reihe von TIF-Dateien enthält, die ebenfalls bereitgestellt werden müssen.

[TestMethod()]
[DeploymentItem(@"files\valid\valid_entries.txt")]
[DeploymentItem(@"files\tif\")]
public void ExistsTifTest()
{
   ...
}

Die Tests haben vorher funktioniert, aber jetzt musste ich die Namen der TIF-Dateien im Verzeichnis \ files \ tif ändern. Gemäß einer Regel müssen die TIF-Dateinamen einem bestimmten Muster entsprechen, das auch von der ExistsTifTest()Methode überprüft wird . Jetzt musste ich die Dateinamen ändern, um sie an die neuen Anforderungen anzupassen, und plötzlich werden die TIF-Dateien nicht mehr wie zuvor bereitgestellt.

Kann mir jemand einen Hinweis geben, warum dies passiert oder was die Ursache sein kann? Das gleiche passiert auch, wenn ich eine neue Textdatei mit dem Namen "my2ndTest.txt" neben "valid_entries.txt" im Verzeichnis \ files \ valid \ mit dem entsprechenden DeploymentItem-Attribut für die Testmethode hinzufüge. Die Datei wird nicht bereitgestellt?

Ich habe die Images jetzt bereitgestellt, indem ich den Bereitstellungspfad direkt in der testrunconfig definiert habe, aber ich möchte verstehen, warum diese Dinge passieren oder warum beispielsweise meine neue Datei "my2ndTest.txt" nicht bereitgestellt wird, während die anderen dies tun.

Juri
quelle
2
Ein großes Problem hierbei ist, dass alle im DeploymentItemAttribute angegebenen Elemente an den Speicherort kopiert werden, von dem aus Ihre Testassemblys ausgeführt werden. Mit anderen Worten, wenn Sie gehofft haben, dass Ihre Verzeichnisstruktur erhalten bleibt, haben Sie kein Glück. Wenn Sie es in ein bestimmtes Verzeichnis kopieren müssen, verwenden Sie die Version DeploymentItem (source, outputDir) mit zwei Parametern. Zu Ihrer Information - Sie können in die alte Schule gehen, um herauszufinden, wo die Dateien für MsTest ausgeführt werden, indem Sie eine System.Console.WriteLine (System.Environment.CurrentDirectory) in einen Ihrer Tests einfügen. NCrunch hatte dieses Problem nicht!
CodeMonkeyKing

Antworten:

111

DeploymentItem ist ein bisschen chaotisch.

Jede Datei in Ihrer Lösung verfügt in VS.NET über die Einstellung "In Ausgabeordner kopieren". Sie müssen "Immer kopieren" (oder ähnlich) sein, um die Dateien in den Ausgabeordner zu bringen.

Überprüfen Sie, ob Sie dieses Set für die neuen Dateien haben. Wenn Sie dieses Set nicht haben, werden die Dateien nicht in den Ausgabeordner kopiert und können dann nicht vom Ausgabeordner in den Ordner bereitgestellt werden, in dem MSTest sie ausführt.

Wenn ich Dateien habe, die ich für meine Komponententests benötige, habe ich festgestellt, dass das Einbetten dieser Dateien als Ressourcen in eine Assembly und das "Entpacken" dieser Assembly während der Tests eine vorhersehbarere Methode ist. YMMV.

Hinweis: Diese Kommentare basieren auf meinen Erfahrungen mit VS2010. Kommentare zu meiner Antwort deuten darauf hin, dass dies mit VS2012 kein Problem ist. Ich stehe immer noch zu Kommentaren, dass die Verwendung eingebetteter Ressourcen weniger "Magie" erfordert und für mich die "Anordnungs" -Stufe meiner Komponententests viel expliziter macht.

Martin Peck
quelle
3
In das Ausgabeverzeichnis kopieren hat keinen Einfluss darauf, wie MSTest Dateien bereitstellt. Diese Antwort ist falsch.
Kzu
19
Unter VS2010 Premium führte das Vornehmen dieser Änderung (und keiner anderen Änderung) dazu, dass die Datei bereitgestellt wurde. Daher schließe ich auf der Grundlage tatsächlicher Beweise, dass dies die Bereitstellung von MsTest beeinflusst.
JonStonecash
1
Einverstanden. Ich habe gesehen, wie diese einzelne Änderung DeploymentItem auf den Kopf gestellt hat.
Martin Peck
2
Dies scheint bei VS2012 nicht mehr erforderlich zu sein. Meine Bereitstellungselemente werden bereitgestellt, wenn "In Ausgabeordner kopieren" auf "Nicht kopieren" eingestellt ist.
Mike
29
Es ist großartig, dass DeploymentItem Sie nicht benachrichtigt, wenn die von Ihnen bereitgestellte einzelne Datei nicht kopiert werden kann.
74

In VS2010 war in meinen Local.testsettings das Kontrollkästchen "Bereitstellung aktivieren" deaktiviert und das Attribut "DeploymentItem" funktionierte nicht. Ich habe es überprüft und alles hat gut funktioniert. Ich hoffe das hilft!

Ivan Muzzolini
quelle
2
Ich habe meinen Kopf seit Ewigkeiten gegen eine Mauer geschlagen, um sie zum Laufen zu bringen ... danke!
Mat-McLoughlin
12
Ich denke, es wäre schön gewesen, wenn das Framework eine Warnung ausgegeben hätte, dass DeploymentItem-Attribute ignoriert werden, wenn diese Einstellung deaktiviert ist. Ich habe auch einen schönen konkaven Eindruck in meinen Schreibtisch gemacht.
Alan McBee - MSFT
2
Beachten Sie, dass Local.testsettings in Solution Items
Matthew Lock
Ich musste auch das Verzeichnis hinzufügen, das die Elemente enthielt, die ich in Local.testsettings bereitstellen wollte: i.imgur.com/p1z3m9R.png
Matthew Lock
Die Verwendung von VS2017 im Jahr 2018 zur Überprüfung der Option "Bereitstellung aktivieren" ist weiterhin die Lösung für dieses Problem. Und leider immer noch Warnung von Visual Studio. Also danke für diese Lösung.
Don H
19

Ich habe auch ähnliche Probleme gehabt, aber ich habe eine einfache 3-Schritt-Lösung dafür gefunden:

Angenommen, Ihre Ordnerstruktur sieht folgendermaßen aus: SolutionFolder\ TestProjectFolder\ SubFolder\

  1. Gehen Sie zu "Lösungselemente / Local.testsettings"> "Bereitstellung"> Aktivieren Sie "Bereitstellung aktivieren".
  2. Wenn Sie VS2010 verwenden, stellen Sie sicher, dass für alle Dateien, die Sie bereitstellen möchten, die Eigenschaft "In Ausgabeordner kopieren" auf "Immer kopieren" oder "Bei Neuem kopieren" festgelegt ist.
  3. Ordnen Sie Ihrer Testmethode Folgendes zu:
    • [DeploymentItem(@"TestProjectFolder\SubFolder")]um den gesamten Inhalt des <SubFolder>Testlaufverzeichnisses bereitzustellen
    • [DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")] um alle Inhalte von <SubFolder>to <TargetFolder>im Test Run-Verzeichnis bereitzustellen

Ein letzter Hinweis zu MSTest (zumindest für VS2010):

Wenn Sie möchten <TargetFolder>, dass der Name denselben Namen wie der hat <SubFolder>, [DeploymentItem(@"SubFolder", @"SubFolder")]schlägt die Verwendung stillschweigend fehl, wenn der MSTest-Läufer auf einen dummen Randfall trifft. Aus diesem Grund sollten Sie <SubFolder>dem <TestProjectFolder>as so Folgendes voranstellen :[DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]

Murari Kumar
quelle
Der Hinweis zum Fehler bei der Benennung des Unterordners ist ein Juwel.
RJ Lohan
1
VS 2015 scheint etwas anders zu sein. Ich musste den Teil "TestPojectFolder" im DeploymentItem-Attribut entfernen.
uli78
15

Um hoffentlich jemand anderem zu helfen: Ich habe alle Vorschläge hier ausprobiert und trotzdem wurde mein Bereitstellungselement nicht kopiert.

Was ich tun musste ( wie hier vorgeschlagen ), war, dem DeploymentItem-Attribut einen zweiten Parameter hinzuzufügen:

[DeploymentItem(@"UnitTestData\TestData.xml", "UnitTestData")]
Peter K.
quelle
10

Wenn Sie in Ihre .testrunconfig-Datei gehen und unter Bereitstellung die Option "Bereitstellung aktivieren" deaktivieren, werden die Tests an ihrem normalen Speicherort ausgeführt, und alles funktioniert wie beim Ausführen der App außerhalb eines Komponententests.

Josh Close
quelle
Hatte auch einige Probleme damit. Als PM habe ich nicht Zugriff auf alle von dev verwendeten Tools. In diesem Fall hat ReSharper die Datei korrekt kopiert, während MSTest dies nicht tat. -> Ich habe Fehler festgestellt, während der Entwickler in Ordnung war. Wechseln Sie zu 'Test-> Testeinstellungen bearbeiten -> Lokale Einstellungen -> Bereitstellung', einschließlich der betreffenden Datei, und beheben Sie dies für meine MSTest-Verwendung.
sonstabo
9

Dies bezieht sich wahrscheinlich nicht auf Ihr genaues Problem, aber hier sind einige Tipps, die ich mit dem Attribut [DeploymentItem] gefunden habe.

  1. In das Ausgabeverzeichnis kopieren sollte auf Immer kopieren eingestellt sein.

Es funktioniert NICHT , wenn es mit dem Attribut [TestInitialize] verwendet wird

[TestInitialize]
[DeploymentItem("test.xlsx")]
public void Setup()
{

Es sollte sich auf Ihrer [TestMethod] befinden, z

    [TestInitialize]
    public void Setup()
    {
        string spreadsheet = Path.GetFullPath("test.xlsx");
        Assert.IsTrue(File.Exists(spreadsheet));
        ...
    }

    [TestMethod]
    [DeploymentItem("test.xlsx")]
    public void ExcelQuestionParser_Reads_XmlElements()
    {
        ...
    }
Matt Frear
quelle
1
Dies ist eine wahnsinnig nervige Einschränkung. Ich bin der Meinung, dass in vielen Fällen die Zeit für die Bereitstellung in Initialize liegen sollte. Was ist, wenn alle meine Tests dieselben unterstützenden Artefakte verwenden? Ich denke, ich soll Dekorateure über Dutzende von Testmethoden kopieren und einfügen? Lächerlich.
Ryanman
5

Nachdem ich alle anderen hier aufgeführten Vorschläge ausprobiert hatte, konnte ich immer noch nicht herausfinden, was los war. Schließlich stellte ich fest, dass im Menü Test / Testeinstellungen keine Einstellungsdatei ausgewählt war, was bedeutete, dass die Bereitstellung nicht aktiviert war. Ich klickte auf den Menüpunkt Test / Testeinstellungen / Testeinstellungsdatei auswählen, wählte die Datei Local.TestSettings aus und dann funktionierte alles.

Mike
quelle
4

Ich bin mir nicht sicher, ob dies die Frage genau beantwortet, aber es kann einigen helfen. Zuerst habe ich festgestellt, dass das Kontrollkästchen "Bereitstellung aktivieren" aktiviert sein muss, damit die Bereitstellung funktioniert. Zweitens sagt das Dokument, dass der Quellpfad "relativ zum Projektpfad" ist, was ich zunächst als Projektordner verstanden habe. Tatsächlich scheint es sich auf den Build-Ausgabeordner zu beziehen. Wenn ich also einen Projektordner mit dem Namen 'TestFiles' und eine Datei Testdata.xmlmit dem Namen 'TestFiles' habe, funktioniert die Verwendung des Attributs auf diese Weise nicht:

[DeploymentItem(@"TestFiles\Testdata.xml")] 

Ich kann die Testdata.xmlDatei markieren Copy Always, so dass der Build eine Kopie unter den Ausgabeordner legt (z Debug\TestFiles\TestData.xml. B. ). Der Bereitstellungsmechanismus findet dann die Kopie der Datei, die sich unter diesem Pfad ( TestFiles\Testdata.xml) relativ zur Build-Ausgabe befindet. Oder ich kann das Attribut folgendermaßen festlegen:

[DeploymentItem(@"..\\..\TestFiles\Testdata.xml")] 

und der Bereitstellungsmechanismus findet die Originaldatei. Copy AlwaysBeides funktioniert also, aber ich habe festgestellt, dass bei Verwendung der Datei app.config in einem Projekt gelegentlich dasselbe Problem auftritt wie beim Bearbeiten der Datei app.config. Wenn ich keinen Code ändere oder keine Neuerstellung erzwinge, wird durch nichts das Kopieren von Dateien ausgelöst, für die markiert ist beim Build kopiert werden.

user1546704
quelle
Der relative Pfad war das Problem für mich und dies hat es behoben. Ich habe zwei Sätze von DeploymentItem-Anweisungen hinzugefügt, je nachdem, wie die Tests ausgeführt wurden.
Ed Bayiates
3

Ich hatte zuerst das Bereitstellungsflag deaktiviert. Aber selbst nachdem ich es aktiviert hatte, wurden aus einem unbekannten Grund noch nicht einmal Ziel-DLLs kopiert. Aus Versehen habe ich das Testlauffenster geöffnet und alle vorherigen Läufe beendet. Auf magische Weise habe ich beim nächsten Lauf alle DLLs und Dateien gefunden, die ich im Testordner benötigte ... Sehr verwirrend.

Schultz9999
quelle
2

Ich hatte große Probleme beim Versuch, Dateien zum Bereitstellen zu bringen - ich habe alle oben genannten Vorschläge ausprobiert.

Dann habe ich VS2010 geschlossen; startete es neu, lud die Lösung und alles funktionierte. (!)

Ich habe nachgesehen; Nachdem Sie das Flag 'Bereitstellung aktivieren' auf local.TestSetting gesetzt haben, sollten Sie den Test nicht einfach über das Fenster Testergebnisse erneut ausführen. Sie müssen den vorherigen Testlauf von der Benutzeroberfläche entfernen, z. B. indem Sie einen anderen Test ausführen oder Ihre Lösung erneut öffnen.

Stephen Westlake
quelle
2

Nicht benutzen DeploymentItem.

Die korrekte Einrichtung ist sehr schwierig und funktionierte weder mit meinem ReSharper-Testläufer noch mit dem nativen für MSTEST in Visual Studio 2017.

Klicken Sie stattdessen mit der rechten Maustaste auf Ihre Datendatei und wählen Sie Eigenschaften aus . Wählen Sie In Ausgabeverzeichnis kopieren: Immer .

Tun Sie dies jetzt in Ihrem Test. Das Verzeichnis ist einfach das Verzeichnis der Datei relativ zum Testprojekt. Einfach.

    [TestMethod()]
    public void ParseProductsTest()
    {
        // Arrange
        var file = @"Features\Products\Files\Workbook_2017.xlsx";
        var fileStream = File.Open(file, FileMode.Open);
        // etc.
    }

Dies scheint mit automatisierten Build- und Testsystemen gut zu funktionieren.

Jess
quelle
1

Da ich das DeploymentItem-Attribut immer als problematisch empfunden habe, verwende ich die Bereitstellung solcher Dateien mithilfe des Post-Build-Skripts. - Stellen Sie sicher, dass für die Dateien, die Sie kopieren möchten, die Eigenschaft Immer kopieren festgelegt ist. - Ändern Sie das Post-Build-Skript Ihres Testprojekts, um die Dateien aus dem Build-Zielordner (Bin \ Debug) an den Speicherort zu kopieren, an dem Ihr Test sie erwartet.

Ismail Hawayel
quelle
1

Versuchen Sie dies für VS2010. So brauchen Sie nicht DeployItems hinzufügen für jeden tif
des Entfernens

[DeploymentItem(@"files\valid\valid_entries.txt")]  
[DeploymentItem(@"files\tif\")]  

Fügen Sie eine Testkonfiguration hinzu.
- Klicken Sie im Lösungs-Explorer mit der rechten Maustaste auf den Lösungsknoten.
- Hinzufügen -> Neues
Element ... - Wählen Sie links den Knoten Testeinstellungen und rechts das Element.
- Klicken Sie auf Hinzufügen

Nennen wir es zB TDD

Wählen Sie TDDunter TestMenu> Edit Testsettings.

Klicken Sie auf die Bereitstellung. Aktivieren Sie es und fügen Sie dann die gewünschten Dateien und Verzeichnisse hinzu. Es gibt einen Pfad relativ zur Lösung. Die Dateien werden angelegt. Die Originaldatei ist zum Beispiel hier:

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate\Authority.xml  

Wenn ich meinen Unit-Test durchführe, wird er kopiert

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate.Tests\bin\Debug\TestResults\Patrik_HERKULES 2011-12-17 18_03_27\Authority.xml  

im Testcode nenne ich es von:

[TestMethod()]
public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary()  
{  
  string authorityFile = "Authority.xml";  
  var Xmldoc = XDocument.Load(authorityFile);  

Es ist nicht erforderlich, Immer kopieren zu wählen. Legen Sie die Dateien in das Testprojekt. Fügen Sie dem Testcode fest codierte Pfade hinzu. Für mich hat diese Lösung am besten funktioniert. Ich habe versucht, mit DeploymentItem immer zu kopieren, aber es war nicht nach meinem Geschmack.

Patrik Lindström
quelle
1

Für diejenigen, die es vorziehen, das Durcheinander von DeploymentItem zu vermeiden und den von @Martin Peck vorgeschlagenen Ansatz zu wählen (akzeptierte Antwort), können Sie den folgenden Code verwenden, um auf den Inhalt der eingebetteten Ressource zuzugreifen:

public string GetEmbeddedResource(string fullyQulifiedResourceName)
{
    var assembly = Assembly.GetExecutingAssembly();
    // NOTE resourceName is of the format "Namespace.Class.File.extension";

    using (Stream stream = assembly.GetManifestResourceStream(fullyQulifiedResourceName))
    using (StreamReader reader = new StreamReader(stream))
    {
        string result = reader.ReadToEnd();
    }
}

Einzelheiten finden Sie in diesem SO-Thread

Sudhanshu Mishra
quelle
1
Ich hatte Probleme mit Assembly.GetExecutingAssembly (), wenn es auf einem Build-Server ausgeführt wurde -> es würde den Testläufer anstelle der eigentlichen Testassembly zurückgeben. Das Beheben der Baugruppe durch Reflektieren von einem festen Typ in der Testbaugruppe (zum Beispiel Ihrer Testklasse) hat dies für mich gelöst.
Arno Peters
1

Für mich war die Hauptursache etwas ganz anderes: Der von meinen Tests ausgeübte Produktionscode war das Umbenennen und / oder Löschen der bereitgestellten XML-Testdatei.

Wenn ich meine Tests einzeln ausführen würde, würden sie bestanden, aber wenn sie alle zusammen ausgeführt würden, würden der zweite und der nachfolgende Test mit "Datei nicht gefunden" -Fehlern fehlschlagen (die ich ursprünglich als DeploymentItemnicht funktionierendes Attribut falsch diagnostiziert hatte ).

Meine Lösung bestand darin, dass jede einzelne Testmethode eine Kopie der bereitgestellten Datei erstellt (unter Verwendung dieser Technik ) und der getestete Produktionscode dann die kopierte Datei anstelle des Originals verwendet.

Jon Schneider
quelle
1

Wir haben viel Zeit mit dem Problem der Bereitstellungselemente verbracht, um es im lokalen Lauf und in der Teamunity-Wiedervereinigung zu lösen. Es ist nicht einfach.

Ein sehr gutes Tool zum Debuggen dieses Problems ist ProcessExplorer . Mit dem Prozess-Explorer können Sie überprüfen, wo Visual Studio nach den Bereitstellungselementen sucht, und das Projekt korrigieren. Filtern Sie einfach alle Dateivorgänge, in denen der Pfad Ihren Deploymentem-Dateinamen enthält, und Sie werden ihn sehen.

Tomas Kubes
quelle
Ich weiß, dass dies eine sehr alte Antwort ist, aber wenn Sie näher erläutern können, wie Sie ProcessExplorer verwenden, wäre dies hilfreich. Ich sehe überhaupt nicht, wie man Dateivorgänge
David
1

Neben dem Deployment-Attribut, das überprüft werden muss, habe ich noch etwas anderes über das DeploymentItem-Attribut entdeckt.

[TestMethod()]
[DeploymentItem("folder\subfolder\deploymentFile.txt")]
public void TestMethod1()
{
   ...
}

Ihre DeploymentFile.txt muss relativ zur Lösungsdatei und nicht zur testfile.cs sein.

Geben Sie hier die Bildbeschreibung ein

Pavenhimself
quelle
Ich habe dies endlich zum Laufen gebracht, indem meine DeploymentItem-Quelle relativ zum Testprojekt war. Ich habe also ein Projekt in meiner Lösung, "Service.Tests". Darunter habe ich einen Ordner "FilesForTests", der die Dateien enthält, die ich kopieren möchte. Ich habe benutzt [DeploymentItem(@"FilesForTests\MyFile.txt", "FilesForTests")]. Ich denke, wir sagen dasselbe?
David
1

Ich habe in VS2013 daran gearbeitet. Meine Erkenntnisse, um dies zum Laufen zu bringen:

  • In das Ausgabeverzeichnis kopieren sollte auf Kopieren gesetzt sein, wenn Neu / Immer kopieren: OBLIGATORISCH.
  • "Bereitstellung aktivieren" in .TestSettings: NICHT ERFORDERLICH. Ich habe dies ohne eine .TestSettings-Datei überhaupt zum Laufen gebracht.
  • Angeben eines Ordners als 2. Parameter: OPTIONAL. Formt das Layout des Ausgabeordners und funktioniert ohne.
  • SPACES im Dateinamen: Dies verursachte mir Kopfschmerzen - die Datei wurde nie kopiert. Das Entfernen der Leerzeichen hat dies behoben. Ich habe noch keine Fluchtcharaktere untersucht.

Ein Tipp, den ich auch auf die harte Tour gelernt habe: Vergessen Sie nicht, dieses Attribut jedem einzelnen Test hinzuzufügen. Die Dateikopien des ersten zugewiesenen Tests im Testlauf wurden jedoch nicht angezeigt, als sich die Reihenfolge der Tests änderte und nicht zugeordnete Tests versuchten, die Datei zuerst zu finden.

Arno Peters
quelle
Ich habe hier alles versucht, bevor ich zu Ihrer Antwort kam, die die allerletzte war. Der Täter: Leerzeichen im Dateinamen! Guter Hinweis.
Joelmdev
1
Verwenden von Visual Studio 2019. "Kopieren, wenn neuer" hat das Problem behoben. Ich hasse "Immer kopieren", weil es das Projekt dazu zwingt, in vielen Szenarien wie Debug oder inkrementeller Erstellung neu zu erstellen.
Gerardo Grignoli
Einverstanden. Ich habe meine Antwort so aktualisiert, dass sie "Kopieren" enthält, wenn sie neuer ist.
Arno Peters
0

Mein großes "Gotcha" war die Art und Weise, wie DeploymentItem Verzeichnisse verarbeitet. Ich habe die Zwei-Parameter-Version mit beiden als Verzeichnispfad verwendet, der Unterverzeichnisse enthält, die ich bereitstellen wollte. Mir war anfangs nicht klar, dass es nur das Zeug in den ROOT des Verzeichnisses kopiert und nicht die gesamte rekursive Ordnerstruktur!

Ich hatte im Grunde [DeploymentItem (@ "Foo \", @ "Foo \")] und erwartete, dass es meine Foo \ Bar bereitstellen würde. Ich musste es speziell in [DeploymentItem (@ "Foo \ Bar \", @ "Foo \ Bar \")] ändern und jetzt funktioniert es wie ein Zauber.

StalePhish
quelle
0

Ich habe auch ähnliche Probleme gehabt. Ich habe alle oben genannten Schritte, aber immer noch kein Glück. Ich benutze VS2010. Dann habe ich festgestellt, dass $ Menü> Test> Aktive Testeinstellung auswählen > Trace und Test Auswirkung ausgewählt wurde. Es begann zu funktionieren, nachdem ich Trace und Test Impact auf Local geändert hatte . Diese Seite enthält sehr einfallsreiche Informationen zum Kopieren von Dateien in den Testergebnisordner. Ich möchte diese Erfahrung ebenfalls hinzufügen.

MJK
quelle