Nie można znaleźć części ścieżki… bin \ roslyn \ csc.exe

Próbuję uruchomić projekt Asp.net MVC pobrany z kontroli źródła TFS. Dodałem wszystkie odwołania do zestawu i jestem w stanie zbudować i skompilować pomyślnie bez żadnych błędów lub ostrzeżeń.

Ale w przeglądarce pojawia się następujący błąd:

Nie można znaleźć części ścieżki „C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe”.

Oto pełny zrzut ekranu ze stroną błędu.

Po kilku dniach badań zrozumiałem, że Roslyn jest platformą kompilatora .Net, która oferuje zaawansowane funkcje kompilacji. Nie rozumiem jednak, dlaczego moja kompilacja próbuje znaleźć \ bin \ roslyn \ csc.exe, ponieważ nie skonfigurowałem niczego związanego z Roslyn ani nie zamierzam używać Roslyn w moim projekcie.

Problem z domyślnymi szablonami VS2015 polega na tym, że kompilator nie jest kopiowany do katalogu tfr \ bin \ roslyn \, a raczej do katalogu {outdir} \ roslyn \

Dodaj ten kod do pliku .csproj:

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

TL; DR

uruchom to w konsoli Menedżera pakietów:

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Więcej informacji

Ten problem nie jest związany z samym programem Visual Studio, więc odpowiedzi sugerujące dodanie kroków kompilacji w celu skopiowania plików są raczej obejściem. To samo dotyczy ręcznego dodawania plików binarnych kompilatora do projektu.

Kompilator Roslyn pochodzi z pakietu NuGet, aw niektórych wersjach tego pakietu występuje błąd (nie wiem dokładnie, które). Rozwiązaniem jest ponowna instalacja / aktualizacja tego pakietu do wersji wolnej od błędów. Pierwotnie zanim napisałem odpowiedź w 2015 roku, naprawiłem ją, instalując następujące pakiety w określonych wersjach:

• Microsoft.Net.Compilers 1.1.1
• Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.1

Potem zajrzałem do .csproj i upewniłem się, że ścieżki do pakietów są poprawne (w moim przypadku .. \ .. \ packages \ *. *) Wewnątrz znaczników <ImportProject>u góry i <Target>na dole z nazwą „ZapewnijNuGetPackageBuildImports”. Dotyczy to MVC 5 i .NET Framework 4.5.2.

Twoja kompilacja próbuje znaleźć, \bin\roslyn\csc.exeponieważ do twojego projektu dodano następujące pakiety. Po prostu przejrzyj swój packages.configplik, możesz mieć je oba

Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Microsoft.Net.Compilers

Co to jest Roslyn i kto dodał je (pakiety) do projektu: Jeśli używasz .NET Framework 4.5.2 do tworzenia projektów przy użyciu VS2015, być może zauważyłeś, że szablony projektów domyślnie używają Roslyn. W rzeczywistości Roslyn jest jednym z kompilatorów typu open source dla języków .NET firmy Microsoft.

Dlaczego powinniśmy usunąć Roslyn: Jeśli twój projekt ma odniesienia do Roslyn i jesteś zainteresowany wdrożeniem go bez serwera, otrzymasz niechciane błędy na stronie, ponieważ wielu dostawców hostingu wciąż nie uaktualniło swoich serwerów, a zatem nie obsługuje Roslyn. Aby rozwiązać ten problem, musisz usunąć kompilator Roslyn z szablonu projektu.

jeśli nie chcesz korzystać z Roslyn, wykonaj poniższe czynności, aby go usunąć

1. Usuń pakiety NuGet, użyj następujących poleceń z konsoli pakietów Nuget

PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers

2. Po wykonaniu tej czynności plik web.config powinien zostać automatycznie zaktualizowany. W przeciwnym razie poszukaj poniższego kodu w web.configpliku, a jeśli go znajdziesz, usuń ten fragment kodu.

<system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701"></compiler>
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+"></compiler>
    </compilers>
</system.codedom>

Czyszczenie i przebudowa działały dla mnie!

Oto więcej sposobów na wykonanie tego przez MSBuild.

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

Ale zauważam, że pliki roslyn są również w moim katalogu bin (nie w folderze). Wygląda jednak na to, że aplikacja działa.

Jak zauważono w numerze w projekcie Roslyn na GitHub , rozwiązaniem (które działało dla mnie) jest po prostu rozładowanie i ponowne załadowanie projektu w Visual Studio.

Folder „bin \ roslyn” nie został utworzony podczas kompilacji lub przebudowy, dopóki nie przeładowałem projektu.

Postępowałem zgodnie z tymi krokami i działało idealnie

• Usuń wszystkie foldery bin i obj
• Wyczyść rozwiązanie i odbuduj
• Uruchom to polecenie w PowerShell

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Po wypróbowaniu wszystkich poprawek bez cygara naprawiłem go, aktualizując ten pakiet Nuget w Visual Studios:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Mój był od 1.0.0 do 2.0.0 w celach informacyjnych (błąd już nie pokazuje)

1. Czyste rozwiązanie
2. Przebuduj rozwiązanie, te dwa kroki działały dla mnie.

Musisz zainstalować Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix, został stworzony specjalnie dla tego błędu

• Kliknij projekt prawym przyciskiem myszy i wybierz Zarządzaj pakietami Nuget
• Znajdź „Microsoft.CodeDom.Providers.DotNetCompilerPlatform”
• Po prostu zaktualizuj do starszej lub nowszej wersji (nie ma znaczenia, która), a następnie zaktualizuj ponownie z powrotem do oryginalnej wersji.

Spowoduje to ponowne zainstalowanie wszystkich zależności i plików pakietu (takich jak csc.exe)

Tak więc odpowiedź Roba Cannona zasadniczo działała dla mnie, ale musiałem dostosować garść opcji. W szczególności musiałem usunąć warunek na obiekcie docelowym, a także zmienić atrybut Include, ponieważ $ CscToolPath był pusty, gdy projekt był budowany na naszym serwerze kompilacji. Co ciekawe, $ CscToolPath NIE był pusty podczas uruchamiania lokalnego.

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" >
  <ItemGroup>
    <RoslynFiles Include="$(SolutionDir)packages\Microsoft.Net.Compilers.1.1.1\tools\*" />
  </ItemGroup>
  <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
  <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

Aktualizacja pakietów nuget działała dla mnie Kliknij prawym przyciskiem myszy rozwiązanie> Zarządzaj pakietami NuGet dla rozwiązania i zaktualizuj wszystkie pakiety, a zwłaszcza: Microsoft.Net.Compilers i Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Jest to znany problem z Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6. Obniżenie wersji do wersji 1.0.5 naprawiło to dla mnie.

W przypadku VS 2019 usuń całkowicie następujący węzeł:

<system.codedom>
</system.codedom>

Na komentarz Daniela Neela powyżej:

Wersja 1.0.3 pakietu Microsoft.CodeDom.Providers.DotNetCompilerPlatform Nuget działa dla mnie, ale wersja 1.0.6 powoduje błąd w tym pytaniu

Przejście na wersję 1.0.3 rozwiązało ten problem.

W moim przypadku miałem problem w Jenkins, gdy próbował wdrożyć go w Octopus z następującym błędem:

MSBUILD : OctoPack error OCT-1676060969: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969: System.Exception: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. ---> System.UriFormatException: Invalid URI: The format of the URI could not be determined. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at System.Uri..ctor(String uriString) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 211 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    --- End of inner exception stack trace --- [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 224 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.CreateOctoPackPackage.AddFiles(XContainer nuSpec, IEnumerable`1 sourceFiles, String sourceBaseDirectory, String targetDirectory, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 443 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.CreateOctoPackPackage.Execute() in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 190 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
Done Building Project "T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj" (default targets) -- FAILED

Przyczyna

Po pewnym czasie korzystałem z wewnętrznego komponentu, który był używany Microsoft.Net.Compilers. Powodem, dla którego wewnętrzny komponent był używany, Microsoft.Net.Compilersbyło przezwyciężenie tego problemu ( C #: wyrzucanie niepoprawnej kompilacji wyrażeń ) i zostało rozwiązane w ten sposób ( Jak korzystać z C # 7 w Visual Studio 2015? ). To powoduje, że kiedy instaluję komponent w głównym programie, Microsoft.Net.Compilersdodaje się go automatycznie.

Rozwiązanie

Moje obejście polegało na odinstalowaniu następujących elementów z naszego wewnętrznego komponentu przez (zgodnie z odpowiedzią @malikKhalil)

PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers

I wybrał kompilator C # 7 w Jenkins zamiast C # 6 i przebudował, aby upewnić się, że wszystko działa i buduje poprawnie.

W końcu w moim głównym programie próbowałem zaktualizować mój wewnętrzny komponent. I wszystko niż budowanie ponownie. Zbudował bez żadnych problemów i problemów.

W moim przypadku musiałem tylko przejść do katalogu bin w Visual Studio Solution Explorer (projekt aplikacji internetowej) i bezpośrednio dołączyć projekt roslyn. Klikając folder prawym przyciskiem myszy i wybierając opcję Uwzględnij w projekcie. I sprawdź ponownie rozwiązanie, aby uruchomić proces kompilacji.

Folder Roslyn nie został domyślnie dołączony.

Uaktualnienie Microsoft.CodeDom.Providers.DotNetCompilerPlatformz 1.0.0 do 1.0.1 naprawiło to dla mnie.

Otwórz plik projektu i usuń wszystkie odwołania za pomocą Import Project = ".. \ packages \ Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0 ....

Otwórz web.config i usuń wszystkie atrybuty kompilatorów system.codedom

Jak już wspomniano przez /programming/32780315#34391473 , szybka poprawka jest użyć menedżera pakietów, Tools> Nuget Package Manager> Package Manager Console, aby uruchomić

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Ale alternatywnym rozwiązaniem (które automatycznie i cicho odtwarza pakiety, jeśli ich brakuje) jest usunięcie atrybutu Web.configpliku projektu .
( Web.configznajduje się w tym samym katalogu co twój.csproj plik).

Otwórz Web.configplik w edytorze tekstu (lub w programie Visual Studio).
- W tagu configuration> system.codedom> compilers> compiler language="c#;cs;csharp"całkowicie usunąć typeatrybut.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- ... -->
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs"
        type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701"/>
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
        type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+"/>
    </compilers>
  </system.codedom>
</configuration>

Krótko mówiąc, usuń linię zaczynającą się od type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.

(Prawdopodobnie ta sama poprawka działa zarówno dla Visual Basic, jak i dla Csharp, ale nie próbowałem.)

Visual Studio zajmie się resztą. Nie więcej Server Error in '/' Application.

W przykładowym kodzie, który podałem w pliku zip powyżej, otrzymasz teraz, HTTP Error 403 gdy naciśniesz Ctrl+ F5.

Spróbuj zamienić http://localhost:64195w przeglądarce na http://localhost:64195/api/products.
Interfejs API sieci Web wyświetla się teraz tak, jak powinien:

Jako prowokację próbowałem usunąć cały packagekatalog mojego rozwiązania Visual Studio.
Został on automatycznie i cicho odtworzony, gdy tylko go (ponownie) zbudowałem.

Last but not least, tutaj jest kod, który odtwarza błąd: http://schulze.000webhostapp.com/vs/SrvrErr-repruce.zip (Oryginalnie z https://github.com/aspnet/AspNetDocs/tree/master/aspnet / web-api / Overview / advanced / call-a-web-api-from-a-net-client / sample / server / ProductsApp )

W moim przypadku po prostu usunięcie wszystkiego z folderu bin i ponowna kompilacja zrobiły dla mnie całą pracę.

Miałem również ten sam problem podczas uruchamiania projektu. Oto kroki, które wykonałem.

1. Kliknij rozwiązanie prawym przyciskiem myszy
2. wybierz Czyste rozwiązanie
3. Po zakończeniu czyszczenia ponownie zbuduj projekt
4. Uruchom projekt ponownie

Tym razem nie widziałem tego samego błędu. Działa to zgodnie z oczekiwaniami.

Jeśli dodajesz ASPNETCOMPILER do kompilacji widoków Razor w MVC, tak jak w tym pytaniu StackOverflow , zmień PhysicalPath na miejsce, w którym znajduje się pakiet nuget Roslyn (zwykle wskazywany przez zmienną $ CscToolPath ):

<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(CscToolPath)" />

Problem z domyślnymi szablonami VS2015 polega na tym, że kompilator nie jest kopiowany do {outdir}_PublishedWebsites\tfr\bin\roslyn\katalogu, a raczej do {outdir}\roslyn\katalogu. Prawdopodobnie różni się to od lokalnego środowiska, ponieważ AppHarborbuduje aplikacje przy użyciu katalogu wyjściowego zamiast budować rozwiązanie „na miejscu”.

Aby to naprawić, dodaj następujący kod na końcu .csprojpliku zaraz po bloku xml<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">...</Target>

<PropertyGroup>
  <PostBuildEvent>
    if not exist "$(WebProjectOutputDir)\bin\Roslyn" md "$(WebProjectOutputDir)\bin\Roslyn"
    start /MIN xcopy /s /y /R "$(OutDir)roslyn\*.*" "$(WebProjectOutputDir)\bin\Roslyn"
  </PostBuildEvent>
</PropertyGroup>

Odniesienie: https://support.appharbor.com/discussions/problems/78633-cant-build-aspnet-mvc-project-generated-from-vstudio-2015-enterprise

W moim przypadku, podobnie jak Basim, istniał pakiet NuGet informujący kompilator, że potrzebujemy C # 6, czego nie zrobiliśmy.

Musieliśmy usunąć pakiet NuGet, Microsoft.CodeDom.Providers.DotNetCompilerPlatformktóry następnie usunął:

1. <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net452" /> z pliku packages.config
2. <system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" /> <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" /> </compilers> </system.codedom>

W system.codedomwęźle możesz zobaczyć, dlaczego przyniósł Roslyn:compilerOptions="/langversion:6

Usuń folder Bin w eksploratorze rozwiązań i ponownie zbuduj rozwiązanie. To rozwiązałoby problem

Miałem ten sam problem podczas instalowania mojej aplikacji na serwerze, gdy wszystko działało idealnie na localhost.

Żadne z tych rozwiązań nie zadziałało, zawsze miałem ten sam błąd:

Could not find a part of the path 'C:\inetpub\wwwroot\myApp\bin\roslyn\csc.exe'

Skończyło się na tym, że:

• w moim projekcie instalacyjnym, kliknij prawym przyciskiem myszy, zobacz> system plików
• utwórz bin/roslynfolder
• wybierz dodaj> pliki i dodaj wszystkie pliki z packages\Microsoft.Net.Compilers.1.3.2\tools

To rozwiązało mój problem.

Uruchom ponownie system Windows.

Jest to jedyne rozwiązanie, które działało dla mnie po próbie przebudowania, usunięcia zawartości bini przebudowania, ponownego uruchomienia programu Visual Studio.

To kolejny przykład tego, jak okropne są narzędzia do budowania C # / .NET.

Myślę (po przeczytaniu wielu odpowiedzi) ogólny wniosek jest taki, że przyczyna i rozwiązanie tego problemu w dużej mierze zależy od konfiguracji i projektu, więc jeśli jedna odpowiedź nie działa, po prostu spróbuj innej. Wypróbuj rozwiązania nieinwazyjne / destrukcyjne, takie jak ponowne uruchomienie programu Visual Studio, ponowne uruchomienie, przebudowa itp., PIERWSZE, zanim zadzwonisz z pakietami NuGet lub ponownie zainstalujesz narzędzia programistyczne. Powodzenia!

(UWAGA: przy użyciu programu Visual Studio 2019, a plik projektu został pierwotnie utworzony w programie Visual Studio 2015. Może to pomoże komuś zbadać problem)

(EDYCJA: Czy może to być spowodowane ponownym uruchomieniem po instalacji / modyfikacji instalacji programu Visual Studio lub aktualizacji programu Visual Studio, gdy instalator wyświetli monit o ponowne uruchomienie?)

Mam webproject bez pliku csproj, a wymienione tutaj rozwiązania nie działały dla mnie.

Zmiana docelowego frameworka .NET, ponowna instalacja pakietów ( Update-Package -reinstall), a następnie zbudowanie projektu działało dla mnie. Możesz nawet zmienić docelową strukturę po tej operacji (upewnij się, że ponownie instalujesz pakiety nuget po tym).