CS1617: Ungültige Option '6' für / langversion; muss ISO-1, ISO-2, 3, 4, 5 oder Standard sein

Dieser Fehler wurde weiterhin angezeigt, wenn eine neue ASP.NET MVC-Anwendung (direkt aus der VS 2015-Community) auf einem Windows 2008 Server-Computer ausgeführt wurde.

Viele Leute stoßen darauf, deshalb wollte ich hier posten.

Dank dieses Typen: Expertdebugger eine verrückte, einfache Problemumgehung gefunden .

Downgraden Sie einfach Ihre Sprachversion von C # 6 auf C # 5 wie folgt:

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

Ändern Sie die langversion:6nach unten von 6 auf 5 -langversion:5

Es wurde für mich behoben. Danke ihm.

Wenn Sie C # 6.0 verwenden möchten:

1. Stellen Sie sicher, dass die .NET-Version Ihres Projekts höher als 4.5.2 ist.
2. Überprüfen Sie anschließend Ihre .configDatei, um die folgenden Änderungen vorzunehmen .

Suchen Sie nach dem system.codedomund ändern Sie es so, dass es wie folgt aussieht:

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

Ich stellte fest, dass die direkte Ursache für den Fehler in meinem Fall war:

Dies ist sinnvoll, da der Fehler besagt, dass es eine ungültige Option für die Sprache gibt.

Aber das hat vorher gut funktioniert - also muss es ausgewählt worden sein. was hat sich geändert? Es stellte sich heraus, dass ein Mitglied meines Teams auf vs 2017 aktualisiert wurde, während ich noch 2015 verwendete. Nachdem er Änderungen am Projekt vorgenommen hatte, wurde die Sprachversion geändert und ich erhielt diese Änderung über die Quellcodeverwaltung. Die ausgewählte Version war jedoch für meine Version von vs nicht verfügbar, daher war sie leer - daher der Fehler. Nach Auswahl eines Werts in der Dropdown-Liste Sprache (ich habe Standard gewählt) ist ein neuer Fehler aufgetreten. Der neue Fehler verursachte einen Buildfehler in allen Codezeilen, die die neuere Version von c # verwendeten. Ich habe den Code geändert, um die gleichen Funktionen auszuführen, aber mit meiner C # -Versionssyntax und meinem Problem gelöst.

Während die direkte Ursache des Fehlers in der Tat eine ungültige Auswahl der Sprachversion war, war die Hauptursache auf widersprüchliche Versionen von vs / c # zurückzuführen.

In meinem Fall war der Fehler:

Fehler CS1617 Ungültige Option 'aktuell' für / langversion; muss ISO-1, ISO-2, Standard oder eine Ganzzahl im Bereich von 1 bis 6 sein.

Ich habe meine .csproj-Datei mit dem Editor geöffnet und diese Zeile gesehen:

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

Ich habe die letzte für eine Ganzzahl im Bereich von 1 bis 6 geändert

<LangVersion>6</LangVersion>

Der Fehler ist verschwunden!

In meinem Fall habe ich die falsche MSBuild.exe verwendet, die in:

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

Um den Fehler zu beheben, habe ich meine Umgebungsvariable PATH aktualisiert, um die Verwendung von Visual Studio 2017 MSBuild.exe zu starten:

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

Weitere Informationen finden Sie unter diesem Link: Fehler CS1056: Unerwartetes Zeichen '$', das den msbuild in einem kontinuierlichen tfs-Integrationsprozess ausführt

in meinem Fall (Projekt in einem anderen System erstellen):

1. Projekt bereinigen (klicken Sie mit der rechten Maustaste auf Projekt im Lösungs-Explorer und klicken Sie auf Element bereinigen).
2. Erstellen Sie dann das Projekt (klicken Sie mit der rechten Maustaste auf das Projekt im Lösungs-Explorer und klicken Sie auf Element erstellen).

Ich kann dieses Projekt ausführen.

Anstatt die Sprachversion von 6 auf 5 zu ändern, ändern Sie das Attribut "type" im Compiler-Tag von

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

zu

Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Aktualisieren Sie das Microsoft.Net.Compilers Nuget-Paket auf die neueste Version (mindestens 2.x).

Die einfachste Lösung für mich war das Upgrade der .NET-Compiler über Package Manager

Installationspaket Microsoft.Net.Compilers

und ändern Sie dann die Web.Config-Zeilen in diese

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

Es stellte sich heraus, dass dies ein Problem war, da das ASP.NET MVC 4-Projekt auf eine bestimmte Version des Microsoft.Net.Compilers-Pakets verwies. Visual Studio verwendete den Compiler aus diesem bestimmten Paket und nicht den Compiler, der ansonsten auf dem Computer installiert wurde.

Eine Warnung oder so wäre von VS2019 nett gewesen :-)

Die Lösung besteht dann darin, das Microsoft.Net.Compilers-Paket auf eine neuere Version zu aktualisieren.

Version 1.x ist für C # 6 Version 2.x ist für C # 7 Version 3.x ist für C # 8 Wie ich das lösen konnte, war nicht sofort klar. Visual Studio hätte vorschlagen oder andeuten können, dass durch die Auswahl einer neuen Version in den Projekteinstellungen diese Einstellung jetzt mit dem im Projekt installierten Paket in Konflikt steht.

(Am Ende habe ich die MSBuild-Protokollierung auf Diagnoseebene aktiviert, um herauszufinden, welche CSC.EXE die IDE wirklich zu verwenden versucht.)

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

Ich habe die Microsoft.Net.Compiler auf Version 2.0 oder höher aktualisiert

Sieh dir das an

Ich habe gerade änderte das die langversionzu defaultund es funktionierte für mich. 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>

Lösung reinigen und erneut erstellen In meinem Fall wurden alle vorherigen Einstellungen aufgrund von Nichtübereinstimmungen blockiert. Ich habe ein neues Projekt importiert und erstellt, versucht, Versionen und alles zu ändern. Reinigen Sie die Lösungen und bauen Sie arbeitete für mich.

In meinem Fall habe ich eine Bibliothek mit Beispielcode für die Keycloak-Implementierung von mattorg von GITHUB heruntergeladen: https://github.com/mattmorg55/Owin.Security.Keycloak/tree/dev/samples

Die Lösung war recht einfach, da ich .Net Framework 4.6.1 verwendet habe, aber das Projekt hat mich am Anfang gebeten, 4.6.2 zu verwenden. Obwohl ich es heruntergeladen habe, wurde es zuerst aktiv ausgewählt, als alle Instanzen von Visual Studion neu zusammengestellt wurden (oder besser alle Instanzen geschlossen wurden). Das Projekt wurde auf 4.6.1 manipuliert (obwohl ich es nicht wünschte und wählte).

Nachdem ich die Konfiguration erneut ausgewählt hatte, um .NET Framework 4.6.1 auszuwählen, verschwand der Fehler sofort.

In meinem Fall war die Fehlermeldung:

ASPNETCOMPILER: Fehler CS1617: Ungültige Option '7.3' für / langversion; muss ISO-1, ISO-2, Standard oder eine Ganzzahl im Bereich von 1 bis 6 sein.

Wie in diesem GitHub-Problem und in diesem Beitrag der VS Developer Community angegeben , scheint es sich um einen Fehler in einem älteren Microsoft.CodeDom.Providers.DotNetCompilerPlatform NuGet-Paket zu handeln.

Nach dem Upgrade dieses NuGet-Pakets auf 3.6.0 blieb der Fehler in meiner Webanwendung bestehen.

Lösung

Ich fand heraus, dass ich einen alten Ordner "bin \ Roslyn" in meiner Webanwendung löschen musste, damit dies funktioniert.

Es scheint, dass das neuere Microsoft.CodeDom.Providers.DotNetCompilerPlatform NuGet-Paket (in meinem Fall 3.6.0) keinen eigenen "Rosyln" -Ordner mehr enthält, und falls vorhanden, hatte dieser alte "Roslyn" -Ordner beim Kompilieren Vorrang.