CS1617: Nieprawidłowa opcja „6” dla / langversion; musi mieć wartość ISO-1, ISO-2, 3, 4, 5 lub wartość domyślną

91

Zachowano ten błąd podczas uruchamiania nowej aplikacji ASP.NET MVC (prosto ze społeczności VS 2015) na komputerze z systemem Windows 2008 Server.

c#  asp.net  asp.net-mvc  iis 
— Kyle Carlson
źródło
3
Zmień wersję językową na 5. Zobacz: Jak zmienić wersję językową
— NASSER
W moim przypadku zaktualizowałem System.Web.Mvc.dll z wersji 5.2.3 do 5.2.7, rozwiązałem ten problem, ponieważ wersja jest nieprawidłowa.
— Dino Liu
W 2019 roku wystąpił podobny błąd . Zobacz także ten powiązany problem z GitHubem .
— Uwe Keim

Odpowiedzi:

104

Wiele osób się na to wpada, więc chciałem zamieścić tutaj.

Znalazłem szalenie łatwe obejście dzięki temu facetowi: Expertdebugger .

Po prostu obniż wersję językową z C # 6 do C # 5, na przykład:

<system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701">
        <providerOption name="CompilerVersion" value="v4.0"/>
      </compiler>
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.VisualBasic.VBCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+">
          <providerOption name="CompilerVersion" value="v4.0"/>
      </compiler>
    </compilers>
</system.codedom>

Zmienić langversion:6 kierunek do dołu z 6 na 5 -langversion:5

Naprawiłem to dla mnie. Podziękuj mu.

— Kyle Carlson
źródło
1
Wielkie dzięki, że mi pomogło.
— AH.
28
To po prostu nakazanie kompilatorowi kompilacji z C # w wersji 5 zamiast 6, co nie jest tym, czego chcesz, jeśli tworzysz projekt .NET 4.6 ... To, co naprawdę musisz zmienić, to typ kompilatora, tak jak jest pokazany druga odpowiedź na to pytanie!
— Nuno Agapito
1
Lub usuń sam blok <system.codedom>, to również rozwiąże problem.
— Anupam Singh
5
Zmień to gdzie? Mam na myśli, gdzie mam umieścić ten kod?
— Unbreakable
Umieść go w swoim pliku web.config lub app.config
— csharpforevermore
82

Jeśli chcesz używać C # 6.0:

  1. Upewnij się, że wersja .NET projektu jest nowsza niż 4.5.2.
  2. A następnie sprawdź .configplik, aby wykonać następujące modyfikacje.

Poszukaj system.codedomi zmodyfikuj go, aby wyglądał tak, jak pokazano poniżej:

<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>
— chsword
źródło
Dokładnie tego szukałem. Ten błąd zaczął pojawiać się po uaktualnieniu projektu ASP.NET MVC z .NET Framework 4.5.2 do 4.6. Nie jestem pewien, ale myślę, że byłoby lepiej, gdyby program Visual Studio sam aktualizował te wiersze.
— Zignd
3
Powinno to być poprawną odpowiedzią, ponieważ faktycznie rozwiązuje problem i umożliwia kompilatorowi korzystanie z najnowszej wersji zamiast powrotu do starej wersji
— SM3RKY
1
Zgadzam się z SM3RKY - ta odpowiedź jest bardziej odpowiednia, ponieważ rozwiązuje problem, a nie omija go!
— Jon Story
Jeśli uaktualnisz swoje rozwiązanie do .net 4.6 dla istniejącego projektu przy użyciu VS 2015 Community lub poniżej, ten błąd wystąpi. Po zaktualizowaniu VS 2015 Update 3 ta poprawka jest domyślnie dostępna dla nowych projektów. Jednak odpowiedź jest dokładna!
— Mahmut C,
To rozwiązało problem w projekcie .Net 4.6.2 przy użyciu ASP.NET (formularzy internetowych) i VB.NET
— Eric Hewett
14

Stwierdziłem, że bezpośrednią przyczyną błędu w moim przypadku było:

build -> advanced -> wersja językowa

ma to sens, ponieważ błąd mówi, że istnieje nieprawidłowa opcja dla języka.

ale wcześniej to działało dobrze - więc musiało zostać wybrane. co się zmieniło? okazuje się, że członek mojego zespołu został uaktualniony do wersji 2017, podczas gdy nadal korzystałem z 2015 r. po wprowadzeniu zmian w projekcie wersja językowa została zmieniona i otrzymałem tę zmianę w kontroli źródła. ale wybrana wersja nie była dostępna dla mojej wersji vs, więc była pusta - stąd błąd. po wybraniu wartości w menu rozwijanym języka (wybrałem domyślny), pojawił się nowy błąd. nowy błąd powodował awarię kompilacji we wszystkich wierszach kodu, w których była używana nowsza wersja języka C #. Zmieniłem kod, aby wykonywał te same funkcje, ale z moją składnią w wersji C # i rozwiązanym problemem.

więc chociaż bezpośrednią przyczyną błędu był rzeczywiście nieprawidłowy wybór wersji językowej, główną przyczyną był konflikt różnych wersji vs / c #.

— Heriberto Lugo
źródło
1
Ta odpowiedź pomogła mi po sprawdzeniu wszystkich innych. dzięki
— MindRoasterMir
1
Ta odpowiedź dotyczy również mojego przypadku, w którym próbowałem uruchomić projekt ustawiony na C # 8, ale nie jest on obsługiwany w moim studiu wizualnym 2017. Tylko VS 2019
— Vinícius Gabriel
13

W moim przypadku błąd był następujący:

Błąd CS1617 Nieprawidłowa opcja „najnowsza” dla / langversion; musi mieć wartość ISO-1, ISO-2, wartość domyślną lub liczbę całkowitą z zakresu od 1 do 6.

Otworzyłem plik .csproj w notatniku i zobaczyłem następującą linię:

<PropertyGroup>
    <LangVersion>latest</LangVersion>
</PropertyGroup>

Ostatnio zmieniłem liczbę całkowitą z zakresu od 1 do 6

<LangVersion>6</LangVersion>

Błąd zniknął!

— nahuelmisc
źródło
Dziękuję Ci bardzo! Teraz debugowanie w VS2015 i Unity2018 działa
— 8Observer8
Nie trzeba go dokładnie otwierać w notatniku, ale ze studia wizualnego można wgrać projekt, a następnie edytować projekt, co również naprawi ten problem.
— Shantu
12

W moim przypadku użyłem niewłaściwego programu MSBuild.exe, znajdującego się w:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319

Aby rozwiązać ten błąd, zaktualizowałem moją zmienną środowiskową PATH, aby rozpocząć korzystanie z programu Visual Studio 2017 MSBuild.exe:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSbuild.exe

Zobacz ten link, aby uzyskać szczegółowe informacje: Błąd CS1056: nieoczekiwany znak „$” uruchamiający msbuild w procesie ciągłej integracji tfs

— user8128167
źródło
To samo tutaj, w moim przypadku zainstalowałem MSBuild Tools i użyłem msbuild z „C: \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \ MSBuild.exe”
— falstaff
10

w moim przypadku (projekt tworzymy w innym systemie):

  1. czysty projekt (kliknij prawym przyciskiem myszy projekt w eksploratorze rozwiązań i kliknij wyczyść element).
  2. następnie buduj projekt (kliknij prawym przyciskiem myszy projekt w eksploratorze rozwiązań i kliknij element kompilacji).

Mogę uruchomić ten projekt.

— Ali Rasouli
źródło
5

Zamiast zmieniać wersję językową z 6 na 5, zmień atrybut „type” w znaczniku kompilatora z

Microsoft.CSharp.CSharpCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

do

Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
— Nwachukwu A. Nnaemeka
źródło
4

Zaktualizuj pakiet Microsoft.Net.Compilers Nuget do najnowszej wersji (co najmniej 2.x)

— wnbates
źródło
3

Najłatwiejszym rozwiązaniem dla mnie była aktualizacja kompilatorów .Net poprzez Menedżera pakietów

Zainstaluj pakiet Microsoft.Net.Compilers

a następnie zmieniając wiersze Web.Config na ten

<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>
— Mikrofon
źródło
1

Okazuje się, że był to problem, ponieważ projekt ASP.NET MVC 4 odwoływał się do określonej wersji pakietu Microsoft.Net.Compilers. Program Visual Studio korzystał z kompilatora z tego konkretnego pakietu, a nie kompilatora zainstalowanego na komputerze w inny sposób.

Ostrzeżenie czy coś byłoby fajne od VS2019 :-)

Rozwiązaniem jest wówczas aktualizacja pakietu Microsoft.Net.Compilers do nowszej wersji.

Wersja 1.x jest dla C # 6 Wersja 2.x jest dla C # 7 Wersja 3.x jest dla C # 8 Sposób rozwiązania tego problemu nie był od razu oczywisty. Program Visual Studio mógł zasugerować lub wskazać, że wybierając nową wersję w ustawieniach projektu, ustawienie powoduje teraz konflikt z pakietem zainstalowanym w projekcie.

(Skończyło się na włączeniu rejestrowania MSBuild na poziomie diagnostycznym, aby dowiedzieć się, którego CSC.EXE IDE naprawdę próbuje użyć)

https://developercommunity.visualstudio.com/content/problem/519531/c-7x-versions-do-not-seem-to-work-in-vs2019.html

— B1zzle
źródło
0

I właśnie zmienił langversionsię defaulti pracował dla mnie. VS 2015

<system.codedom>
<compilers>
  <compiler language=”c#;cs;csharp” extension=”.cs” type=”Microsoft.CSharp.CSharpCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ warningLevel=”4″ compilerOptions=”/langversion:default /nowarn:1659;1699;1701″>
    <providerOption name=”CompilerVersion” value=”v4.0″/>
  </compiler>
  <compiler language=”vb;vbs;visualbasic;vbscript” extension=”.vb” type=”Microsoft.VisualBasic.VBCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ warningLevel=”4″ compilerOptions=”/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+”>
      <providerOption name=”CompilerVersion” value=”v4.0″/>
  </compiler>
</compilers>

— Kumar
źródło
0

Wyczyść rozwiązanie i skompiluj ponownie W moim przypadku, jakiekolwiek poprzednie ustawienia blokowały się z powodu niezgodności. Zaimportowałem nowy projekt i zbudowałem go, próbowałem zmienić wersje i tak dalej. wyczyść rozwiązania i kompilacja zadziałała dla mnie.

— Sumanstm21
źródło
0

W moim przypadku pobierałem bibliotekę z przykładowym kodem implementacji Keycloak firmy mattorg z GITHUB: https://github.com/mattmorg55/Owin.Security.Keycloak/tree/dev/samples

Rozwiązanie było dość proste, ponieważ użyłem .Net Framework 4.6.1, ale projekt na początku błagał mnie o użycie 4.6.2. Chociaż go pobrałem, został on najpierw aktywnie wybrany, kiedy ponownie ustawiłem wszystkie instancje Visual Studion (lub lepiej zamknąć wszystkie instancje). Projekt został zmanipulowany do 4.6.1 (chociaż nie chciałem i tak wybrałem).

Po ponownym wybraniu konfiguracji, aby wybrać .Net Framework 4.6.1, błąd zniknął natychmiast.

— pedda
źródło
0

W moim przypadku komunikat o błędzie brzmiał:

ASPNETCOMPILER: błąd CS1617: Nieprawidłowa opcja „7.3” dla / langversion; musi mieć wartość ISO-1, ISO-2, wartość domyślną lub liczbę całkowitą z zakresu od 1 do 6.

Jak wspomniano w tym problemie GitHub i tym poście społeczności programistów VS , wydaje się, że jest to błąd w starszym pakiecie NuGet Microsoft.CodeDom.Providers.DotNetCompilerPlatform .

Po uaktualnieniu tego pakietu NuGet do wersji 3.6.0 błąd nadal występował w mojej aplikacji sieci Web.

Rozwiązanie

Dowiedziałem się, że muszę usunąć stary folder „bin \ Roslyn” w mojej aplikacji sieci Web, aby to zadziałało.

Wygląda na to, że nowszy pakiet Microsoft.CodeDom.Providers.DotNetCompilerPlatform NuGet (w moim przypadku 3.6.0) nie zawiera już własnego folderu „Rosyln”, a jeśli jest obecny, pierwszeństwo podczas kompilacji miał ten stary folder „Roslyn”.

— Uwe Keim
źródło
0

Zdarzyło mi się to, kiedy ściągnąłem repozytorium po przeniesieniu go w nowe miejsce. Rozwiązaniem było wyładowanie, a następnie ponowne załadowanie każdego projektu, który wyświetlał ten błąd.

Wypróbowałem kilka innych opcji, ale nic mi nie pomogło. Również w tej sytuacji moje pliki konfiguracyjne były ustawione na język w wersji 6, więc ustawienie ich na domyślne nie rozwiązało problemu.

— Brendan Sluke
źródło
0

Jeśli powyższe opcje nie działają, a korzystałeś z pakietów NuGet, takich jak Microsoft.Net.Compilers i CodeDom, i nadal nie działają, występuje problem z plikiem projektu w otwartym pliku projektu. Plik projektu używa jednej z opcji kompilatora, która nie obsługuje wybranego języka. Otwórz plik projektu za pomocą notatnika ++ i usuń następujący wiersz.

Oryginalny plik projektu

<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="..\packages\Microsoft.Net.Compilers.Toolset.3.7.0\build\Microsoft.Net.Compilers.Toolset.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.Toolset.3.7.0\build\Microsoft.Net.Compilers.Toolset.props')" />
  <Import Project="..\packages\Microsoft.Net.Compilers.3.7.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.3.7.0\build\Microsoft.Net.Compilers.props')" />
  <Import Project="..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
  <!--Don't delete below one-->
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />

Usuń następujące wiersze

  <Import Project="..\packages\Microsoft.Net.Compilers.Toolset.3.7.0\build\Microsoft.Net.Compilers.Toolset.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.Toolset.3.7.0\build\Microsoft.Net.Compilers.Toolset.props')" />
  <Import Project="..\packages\Microsoft.Net.Compilers.3.7.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.3.7.0\build\Microsoft.Net.Compilers.props')" />
  <Import Project="..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
— Ali
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.