Nie można znaleźć pliku testhost.dll. Opublikuj projekt testowy i spróbuj ponownie

113

Mam prostą bibliotekę klas rdzenia dotnet z pojedynczą metodą testową XUnit:

TestLib.csproj:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.SDK" Version="15.9.0" />
    <PackageReference Include="xunit" Version="2.4.1" />
    <PackageReference Include="xunit.runner.console" Version="2.4.1">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.1">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="xunit.runners" Version="2.0.0" />
  </ItemGroup>

</Project>

BasicTest.cs:
using Xunit;

namespace TestLib
{
    public class BasicTest
    {
        [Fact(DisplayName = "Basic unit test")]
        [Trait("Category", "unit")]
        public void TestStringHelper()
        {
            var sut = "sut";
            var verify = "sut";

            Assert.Equal(sut, verify);
        }
    }
}

Jeśli wprowadzę projekt w interfejsie wiersza polecenia i wpiszę dotnet buildkompilacje projektu. Jeśli piszę dotnet test, otrzymuję to:

C:\git\Testing\TestLib> dotnet test
C:\git\Testing\TestLib\TestLib.csproj : warning NU1701: Package 'xunit.runner.visualstudio 2.4.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Build started, please wait...
C:\git\Testing\TestLib\TestLib.csproj : warning NU1701: Package 'xunit.runner.visualstudio 2.4.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Build completed.

Test run for C:\git\Testing\TestLib\bin\Debug\netstandard2.0\TestLib.dll(.NETStandard,Version=v2.0)
Microsoft (R) Test Execution Command Line Tool Version 16.0.0-preview-20181205-02
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
Unable to find C:\git\Testing\TestLib\bin\Debug\netstandard2.0\testhost.dll. Please publish your test project and retry.

Test Run Aborted.

Co muszę zmienić, aby uruchomić test?

Jeśli to pomoże, program VS Code nie wyświetla testów w eksploratorze testów.

Matt W.
źródło
W moim przypadku chodziło o to, że nie można faktycznie uruchamiać testów względem netstandard2.0, ponieważ jest to definicja API, a nie środowisko wykonawcze. Jeśli zmienisz TFM na net472, wszystko działa dobrze. Alternatywnie możesz na przykład kierować na wiele celów do netcore + net472 i działać przeciwko obu.
kzu

Odpowiedzi:

25

W moim przypadku problem polegał na tym, że celowałem w .NET Core 2.0 i przejście na .NET Core 2.1 rozwiązało problem. Jednak używałem Microsoft.NET.Test.SDK 16.4.0 zamiast 15.9.0.

Andreas
źródło
178

Zainstalowanie Microsoft.NET.Test.Sdkpakietu z menedżera pakietów NuGet rozwiązało mój problem.

R15
źródło
Zostało to już uwzględnione w moim poście - ale masz rację: będą duże problemy z uruchamianiem testów jednostkowych z rdzeniem dotnet bez tego.
Matt W
2
„Microsoft.NET.Test.Sdk” był brakującym elementem po dodaniu projektu biblioteki klas i przekształceniu go w projekt testowy. Prawdopodobnie najlepszym rozwiązaniem byłoby, aby dodać nowy projekt testowy następnie dodać potrzebne pakiety Nuget jak Rhino lub Min etc ...
Yawar Murtaza
3
Utworzono .NET standardowa 2,0 lib, dodał xunit, xunit.runner.visualstudioa Microsoft.NET.Test.Sdkdo projektu, jeszcze tego samego rezultatu. Myślę, że w grę wchodzi jeszcze jeden czynnik ...
Manfred
12
Problem w moim przypadku był spowodowany utworzeniem netstandard2.0projektu zamiast netcoreapp2.2projektu. Jak tylko przeszedłem na to drugie, zadziałało. Jedynymi Nuget pakiety były mi potrzebne xunit, xunit.runner.visualstudioi Microsoft.NET.Test.Sdk.
Manfred
1
Zainstalowanie Microsoft.NET.Test.Sdk też mi nie dotnet clean
pomogło, Póki
26

Utworzyłem bibliotekę klas i próbowałem użyć w niej pakietu XUnit NuGet.

To, co powinienem był zrobić, to utworzenie projektu XUnit za pomocą tego polecenia: dotnet new xunit -n TestProject

Znalazłem tę pomocną stronę .

Matt W.
źródło
3
Po wykonaniu tego polecenia możesz chcieć zaktualizować nuget pakiety, odwołując się do nowego projektu.
Manfred
Lub zainstaluj nuget xunit.runner.visualstudion w istniejącym projekcie;)
Lukáš Kmoch
Czy to pomyłka? Nie mogę znaleźć tego.
Matt W
Jeśli masz istniejący projekt, możesz przekazać jego nazwę, --forceaby wymusić na nim przebudowę projektu jako projekt testowy xUnit. Zgodnie z komentarzem @ Manfred, musisz zaktualizować / ponownie dodać wszelkie odniesienia do projektów, które miałeś w tym projekcie.
Myles
1
@MattW Tak, to wygląda na literówkę. Myślę, że @Lukas miał na myśli, xunit.runner.visualstudioco można znaleźć na stronie nuget.org/packages/xunit.runner.visualstudio
Manfred,
14

W moim przypadku problem polegał na tym, że mam projekt rozszerzenia dla xunit. Istnieje również projekt testowy do testowania rozszerzeń. Kiedy uruchomiłem dotnet testswoje rozwiązanie, mój projekt rozszerzenia został również odebrany jako projekt testów jednostkowych (uświadomienie sobie tego zajęło mi trochę czasu). Powodem tego jest to, że odwołuje się do niektórych pakietów xunit. Jeden z tych pakietów xunit automatycznie ustawia <IsTestProject>true</IsTestProject>właściwość w pliku csprj. To właściwie dobra rzecz, ponieważ 99,99% projektów, które odwołują się do xunit, to w rzeczywistości testy jednostkowe. Mogłem w końcu rozwiązać ten problem poprzez jawne ustawienie

     <PropertyGroup>
...
        <IsTestProject>false</IsTestProject>
...
      </PropertyGroup>

Ręcznie w moim pliku csproj. Wtedy problem zniknął.

Willy Van den Driessche
źródło
12

Zdarzyło mi się to po aktualizacji Microsoft.NET.Test.Sdk z wersji 16.2.0 do wersji 16.4.0 z <TargetFramework>netcoreapp2.0</TargetFramework>. Aktualizacja, aby <TargetFramework>netcoreapp3.0</TargetFramework>rozwiązać problem za mnie.

SteveHansen
źródło
10

Naprawiono to, instalując xunit.runner.visualstudio.

Eugene Ihnatsyeu
źródło
10

Jeśli używasz xUnit, upewnij się, że typ projektu nie jest taki jak netstanderd. Ponieważ xUnit nie obsługuje netstanderd , zmień go na coreapp2.0 lub inne.

Raj kumar
źródło
To był w szczególności mój problem. No! Powinienem był to złapać wcześniej. Dziękuję za twoją odpowiedź, ponieważ skierowała mnie na właściwą ścieżkę :)
Dev Leader
Zmiana projektu testowego na aplikację .Net Core umożliwiła poprawną instalację pakietu xunit.runner.visualstudio. Zwróć uwagę, że prawdopodobnie będziesz musiał zamknąć swoje rozwiązanie i załadować je ponownie, aby VisualStudio uporządkował zmiany.
Sheldon
10

Spotkałem się z tym kilka razy i zawsze zapominam, co się dzieje. Ostatnio miałem:

  • Biblioteka klas -> kierowanie .NET Core 3.0
  • Projekt testowy -> Kierowanie .NET Core 3.1

Pakiety do mojego projektu testowego:

  • Moq -> 4.14.1
  • xUnit -> 2.4.1
  • xUnit.Runner.VisualStudio -> 2.4.2

Widziałem:

Nie można znaleźć C: \ PATH \ bin \ Debug \ netstandard2.0 \ testhost.dll. Opublikuj projekt testowy i spróbuj ponownie.

Wszystko, co musiałem zrobić, to dodać do mojego projektu testowego brakujący pakiet NuGet: „Microsoft.NET.Test.SDK”

W tym momencie wszystko wróciło do normy.

Dev Leader
źródło
8

Znalazłem bardzo interesujący problem ze zgodnością z wersją. Zaktualizowałem swój kod, tak jak zwykle, i przełączyłem się na xUnit.runner.visualstudio 2.4.2. Przestał działać w .Net Core 3.1. Musiałem przejść na starszą wersję 2.4.1 i znowu zaczęło działać.

Dodatkowe informacje po jednym z moich komentarzy.

Pakiet xunit.runner.visualstudio w wersji <= 2.4.1 zawiera odniesienie do Microsoft.NET.Test.Sdk. Późniejsze wersje nie, więc musisz dodać odwołanie do swojego projektu.

Zobacz stackoverflow.com/a/63786758/3248302

Maximiliano Rios
źródło
1
Miałem ten sam problem - w przypadku niektórych projektów testowych w moim rozwiązaniu. Wspólną przyczyną niepowodzeń projektów testowych po aktualizacji do wersji 2.4.2 był brak w nich Microsoft.Net.Test.Sdk (nigdy wcześniej nie było to problemem). Dodano nuget 16.6.1 i wróciłem do pracy.
bit0001
Fajnie, nie wiedziałem tego. Obniżyłem ocenę, żeby to działało
Maximiliano Rios
1
Naprawiłem to w ten sam sposób. Problem rozwiązany został downgrade pakietu xUnit.runner.visualstudio do wersji 2.4.1.
Jacek Labuda
1
Mogę potwierdzić, że jest to nadal problem z wersją 2.4.3 xunit.runner.visualstudio. Downgrade do 2.4.1 rozwiązuje problem.
bN_
1
xunit.runner.visualstudiowersje <= 2.4.1 zawierają odniesienie do Microsoft.NET.Test.Sdk. Późniejsze wersje nie, więc musisz dodać odwołanie do swojego projektu. Zobacz stackoverflow.com/a/63786758/3248302 .
Blisco
5

Budowałem projekt testowy netcoreapp2.2, a następnie próbowałem uruchomić go dotnet vstestz folderu bin. Zauważyłem, że biblioteki DLL Microsoft Test z:

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.0.1" />

nie były przesyłane do mojego folderu bin. Zamiast po prostu budować, uruchomiłem publikację, która zawierała niezbędne biblioteki DLL w folderze wyjściowym i mogłem dotnet vsteststamtąd uruchomić .

Michael Armitage
źródło
3

Jeśli celujesz w netstandard2.0, to nie zadziała. Jeśli używasz platformy .NET Core. upewnij się, że plik .csproj zawiera następujące wiersze:

<TargetFramework>netcoreapp3.0</TargetFramework>

a także zawiera pakiet Microsoft.NET.Test.Sdk

Hakakou
źródło
2

Ten sam problem napotkałem w przypadku projektu Nunit (.net core 3.1). Używałem Microsoft.NET.Test.SDK 16.6.1, obniżyłem wersję do 15.9.0. I zaczyna działać

SaifAli Sanadi
źródło
1

Wystąpił ten błąd, główną przyczyną było to, że testy osiągały maksymalną długość ścieżki systemu Windows (MAX_PATH), która jest zdefiniowana jako 260 znaków.

S1r-Lanzelot
źródło
1

Ten błąd może wystąpić w przypadku uaktualnienia xunit.runner.visualstudiodo wersji nowszej niż 2.4.1. Wersje do 2.4.1 włącznie zawierają odniesienie doMicrosoft.NET.Test.Sdk ale późniejsze nie, więc musisz włączyć to odniesienie do własnego projektu.

Co ciekawe, odkryłem, że NCrunch nadal przeprowadzał moje testy bez dodatkowego odniesienia, mimo że nie mogłem ich uruchomić przez CLI.

Blisco
źródło
0

Jeśli uruchamiasz projekt przez klonowanie, rozwiązaniem jest zainstalowanie Microsoft.NET.Test.Sdk. Instrukcje: narzędzia> Menedżer pakietów NuGet> Zarządzaj pakietami NuGet w poszukiwaniu rozwiązania ...> Wyszukaj Microsoft.NET.Test.Sdk i zainstaluj projekt testowy.

Shawon Barua
źródło
0

Może to być również spowodowane nieumyślną próbą uruchomienia projektu niebędącego testem, co zwykle dzieje się, gdy filtr plików testowych jest zbyt szeroki.

reim
źródło
0

Wystąpił ten błąd podczas próby debugowania testu jednostkowego. Poniżej znajdują się kroki, które próbowałem.

  • Krok 1: Zainstalowałem Microsof.TestPlatform.TestHost i próbowałem uruchomić test, ale bez powodzenia.
  • Krok 2: Zmieniono platformę docelową z .NET Core 2.0 na 2.1 i próbowałem uruchomić test, ale bez powodzenia.
  • Krok 3: Zamknięto i otworzyłem VS2017 i próbowałem uruchomić.

Yay !!! zadziałało :-) Nigdy nie przegap ostatniego kroku ;-) Mam nadzieję, że pomoże to komuś takiemu jak ja.

Venu
źródło
0

Musiałem dodać, Microsoft.TestPlatform.TestHostżeby dostać testhost.dll. Znalazłem to w tej odpowiedzi https://github.com/dotnet/sdk/issues/7171#issuecomment-261506546

Ękwav
źródło
Fajnie, że dajesz kredyt innym osobom, ale tutaj, w przypadku stackoverflow, wolimy, abyś zawierał również wystarczającą ilość informacji. Na wypadek, gdyby podany przez Ciebie link do strony internetowej pewnego dnia był uszkodzony / nieważny.
tgolisch
OK, ponownie odwiedziłem link, nie ma żadnych informacji do dodania do mojej odpowiedzi. Powinienem więc lepiej go usunąć?
Ękwav,
1
Właściwie twoja odpowiedź wydaje się pomocna. Nie sugeruję, żebyś go usunął. Standardy społeczności zalecają, aby Twoja odpowiedź zawierała informacje zamiast linku (parafrazuj, ale nie plagiatuj), więc informacje są w S / O, bez konieczności klikania.
tgolisch
0

W moim przypadku konieczne było dołączenie odwołania do modułu MsTest.TestAdapter przy użyciu nuget.

Świeży projekt z MSTest.TestFramework i Microsoft.Net.Test.Sdk nie wystarczył do uruchomienia pojedynczego testu jednostkowego.

Zauważyłem, że w moim przypadku korzystałem z projektu testowego ukierunkowanego na .NET Framework 4.8, a nie .NET Core. Chociaż jestem przekonany, że ta poprawka może dotyczyć również tej platformy

Aislan Gelatti Rocha
źródło