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

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.

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.

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

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ę .

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ął.

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.

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

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.

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.

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

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ć .

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

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ć

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.

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.

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.

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.

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.

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

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