Twój projekt nie odwołuje się do frameworka „.NETFramework, Version = v4.6.2”. Dodaj odniesienie do „.NETFramework, Version = v4.6.2” w „TargetFrameworks”

Nie mogę uruchomić moich testów jednostkowych.

Mam następny błąd:

Twój projekt nie odwołuje się do struktury „.NETFramework, Version = v4.6.2”. Dodaj odwołanie do „.NETFramework, Version = v4.6.2” we właściwości „TargetFrameworks” pliku projektu, a następnie ponownie uruchom przywracanie NuGet.

W app.config:

<startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.2"/>
</startup>

W projekcie> Właściwości> aplikacji> TargetFramework (.NET Framework 4.6.2)

Jak mogę to naprawić?

Proszę wykonać następne kroki

1. Czyste rozwiązanie
2. Wyczyść „pakiety” folderu
3. Usuń folder „bin”
4. Usuń folder „obj”

Miałem podobny problem, ale z v4.7.2. Mianowicie, ciągle otrzymywałem następujący komunikat dziennika kompilacji:

error : Your project does not reference ".NETFramework,Version=v4.7.2" framework. Add a reference to ".NETFramework,Version=v4.7.2" in the "TargetFrameworks" property of your project file and then re-run NuGet restore.

Pomimo tego, że wyglądało podobnie, żaden z proponowanych powyżej kroków nie zadziałał. Widziałem ten komunikat po każdej kompilacji. Wydawało się, że nic nie jest w stanie pomóc.

W rzeczywistości problem był związany z tym, że z powodu migracji musiałem umieścić dwa projekty w jednym folderze kodu. Jeden z nich był skierowany do .Net Core , drugi do .Net Framework , oba odwoływały się do tych samych bibliotek .Net Standard. Najwyraźniej dzielą ten sam objfolder, w którym umieszczają project.assets.jsonplik projektów Core . Właściwie to dokładnie ten plik koliduje z projektem Framework, uniemożliwiając jego normalną kompilację. Wydaje się, że nawet jeśli wykonałeś migrację z packages.config do PackageReference ... co było zalecane jako jedno z możliwych rozwiązań.

Możesz spróbować rozwiązać problem, umieszczając następujący fragment kodu w pliku projektu Framework:

<Project>
  ...
  <PropertyGroup>
    <BaseOutputPath>$(MSBuildProjectDirectory)/out/$(MSBuildProjectName)/bin</BaseOutputPath>
    <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/out/$(MSBuildProjectName)/obj</BaseIntermediateOutputPath>
  </PropertyGroup>
  ...
</Project>

U mnie od razu zadziałało, dopiero później uważnie przeczytałem, dlaczego tego potrzebujemy i dlaczego działa. I nagle okazało się, że w części 2 o migracji aplikacji WPF próbki do .NET Core 3 pod Upewniwszy projekt Framework nadal buduje odcinek. BaseOutputPathi BaseIntermediateOutputPathzmienne msbuild można tam znaleźć, nie jestem pewien, czy są one dobrze udokumentowane w dowolnym miejscu.

Zdarzyło mi się to podczas otwierania projektu VS2015 w VS2017. Usunięcie pliku project.assets.jsonz objfolderu załatwiło sprawę.

Zresztą w pliku brakowało Framework z wiadomości, jednak nie dodałem go tam, poszedłem z jego usunięciem.

Głosowałem za Larissą, ale pomyślałem, że warto wiedzieć, jak się w to wpakowałem. Dodałem standardowy plik projektu .net do mojej kompilacji (celujemy w wiele platform) i utworzyłem śmieci znalezione w folderze obj. Kiedy pojawiła się kompilacja dla Androida, zwróciła się do folderu obj. Moim rozwiązaniem było wyczyszczenie tego folderu jako krok przed kompilacją. To trudny problem, ponieważ przez lata działał dobrze ... igła na stogu siana.

W moim przypadku usuń .pkgrefgen/folder w folderze projektu działa, zawiera plik project.assets.json, który odwołuje się do starej platformy .net

Wpadłem na to samo z .net 4.71. W moim przypadku po prostu przeprowadziłem migrację z packages.config do "odniesień do pakietów" na

Przeprowadź migrację z packages.config do PackageReference

... i to rozwiązało mój problem. Dla mnie i tak zamierzałem to zrobić, więc jeśli już to robisz, po prostu pominę powyższe i dokonam migracji do odniesień do pakietów.

Używam bardzo starego projektu .NET i działał dobrze, dopóki nagle się nie zatrzymał. Uaktualnienie Visual Studio naprawione dla mnie ty.