2016-07-29 12 views
2

Ich habe eine dotnet CLI WebApp in Visual Studio mit der neuen Xproj-Erweiterung und project.json.Keep IIS Express läuft auf dotnet cli Web-Projekt targetting. NetCoreApp

dotnet new --t web --lang c# 

Ich habe eine Website arbeiten und läuft auf .NetCoreApp ganz gut. Wie auch immer, ich kann die Site nicht in IIS laden, ohne Middleware hinzuzufügen, abhängig von IIS, was ich lieber nicht tun würde.

So verwende ich IIS Express.

Dafür muss ich das Projekt ausführen, um IIS zu erhalten, um im Debug-Modus die Website verwenden zu können.

Was ich gerne wissen würde ist, wie ich IIS Express zum Laufen bringen und stattdessen anhängen kann, wenn ich das Projekt ausführen.

Ich habe alle Anleitungen zum Deaktivieren von "Bearbeiten und Fortfahren" gelesen. Das funktioniert tatsächlich in ASP.Net Web Applications, aber dies ist eine dotnet Core WebApp und ist nicht derselbe Projekttyp. Es verfügt nicht über ein Eigenschaftsfenster mit Optionen zum Deaktivieren von Bearbeiten und Weiter und das Deaktivieren von Bearbeiten und Fortfahren in den Debug-Optionen der IDE hat keine Auswirkungen.

IIS wird geschlossen, wenn ich das Projekt abbringe.

Irgendwelche Ideen?

Optional, wie kann ich es konfigurieren, um lokal in IIS zu laufen, ohne darauf angewiesen zu sein, die beste Option, die ich dort heraufkommen kann, ist Bedingte Kompilierung.

+0

Sie sollten die Beschreibung erneut überprüfen und eine klare Unterscheidung zwischen IIS und IIS Express vornehmen. Momentan mischen Sie die beiden und die Frage ist schwer zu verstehen. –

+0

Das ganze ist jetzt irgendwie irrelevant, dass ich herausgefunden habe, wie man "dotnet run" benutzt, was ich wollte. Mein Ziel war es, meine Website ohne den angehängten Debugger laufen zu lassen. Dotnet Run und Turmfalke funktioniert gut dafür. Ich werde diese Frage in Kürze löschen. –

+0

@Ryios Bitte lösche diese Frage nicht, sondern buche deine Lösung als Antwort. Danke – objectNotFound

Antwort

5

Der ganze Zweck meiner Frage war, in der Lage zu sein, meine Site laufen zu lassen, ohne f5 in Visual Studio zu verwenden und ohne den Debugger angeschlossen zu haben.

Die Lösung, stellt sich heraus, ist einfach.

Sie können es einfach in Kestrel in einem Konsolen-Terminal ausführen.

Öffnen Sie einfach ein Terminal oder Eingabeaufforderung, um Ihre Projekte Wurzel und Typ:

dotnet run 

Dies wird Kestrel gegen das Projekt laufen und Ihnen sagen, was es ist Port auf. Dann können Sie http://localhost:5000 (oder w/e der Port ist) in Ihrem Browser treffen.

Update: Sie können Ihre Abhängigkeit von IIS Express auch in Ihrer gesamten App töten und f5 in Kestrel laufen lassen.

dies zu tun:

  1. Rechts Ihr Projekt klicken und
  2. Klicken Sie auf die Registerkarte Debuggen
  3. Klicken Sie auf Neu neben dem Profil Dropdown
  4. Nennen Sie es Kestrel Dev
  5. gehen auf Eigenschaften Ändern Sie den Starttyp in "Projekt"
  6. Setzen Sie die Anwendungsargumente auf "dotnet run"
  7. eine Umgebungsvariable für "ASPNETCORE_ENVIRONMENT"
  8. den Wert auf "Entwicklung"
  9. eine Umgebungsvariable hinzufügen Für "ASPNETCORE_URLS"
    1. sie einen Wert von Give "http://localhost:8080" hinzufügen oder welche URL/Port auch immer Sie laufen möchten.

Wiederholen Sie die oben genannten Optionen für "Kestrel Production" gesetzt, aber die ASPNETCORE_ENVIRONMENT auf "Produktion"

Die ASPNETCORE_ENVIRONMENT verwendet wird Ihre json Config Transformationen zu verarbeiten.

public Startup(IHostingEnvironment env) 
    { 
     var builder = new ConfigurationBuilder() 
      .SetBasePath(env.ContentRootPath) 
      .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true) 
      .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true) 
      .AddEnvironmentVariables(); 

     Configuration = builder.Build(); 
    } 

Was also, wenn Sie appSettings.json für Entwicklung (lokale) wollen, Staging und Produktion dann erstellen Sie 3 appSettings.json Dateien

appSettings.json 
appSettings.Development.json 
appSettings.Staging.json 
appSettings.Production.json 

Dann machen Sie die .Staging.Json etc Dateien optional mit der Option: True Config Option oben.

Also in appSettings.json haben Sie alles, was in allen Umgebungen gleich ist.

Dann in AppSettings.Development.json können Sie Dinge haben, die Sie nur wollen, wenn sie lokal ausgeführt werden.

etc etc

Sie ein Profil für jede Umgebung erstellen, so dass, wenn Sie "Kestrel Development" führen Sie es verwendet appSettings.Development.Json

Wenn Sie "Kestrel Staging" führen Sie es verwendet appSettings.Staging .Json.

Wenn Sie "Kestrel Production" ausführen, verwendet es appSettings.Production.json.

Dies wirkt sich auch auf die Funktionsweise Ihres tagHelper in Ihren MVC-Ansichten aus, z.

<environment names="Development"> 
    <link rel="stylesheet" href="~/lib/bootstrap/dist/css/bootstrap.css" /> 
    <link rel="stylesheet" href="~/css/site.css" /> 
</environment> 
<environment names="Staging,Production"> 
    <link rel="stylesheet" href="https://ajax.aspnetcdn.com/ajax/bootstrap/3.3.6/css/bootstrap.min.css" 
      asp-fallback-href="~/lib/bootstrap/dist/css/bootstrap.min.css" 
      asp-fallback-test-class="sr-only" asp-fallback-test-property="position" asp-fallback-test-value="absolute" /> 
    <link rel="stylesheet" href="~/css/site.min.css" asp-append-version="true" /> 
</environment> 

In diesem html, wenn Sie "Kestrel Development" laufen dann die html in der Umgebung Tag für die Entwicklung ausgegeben.

Wenn Sie Kestrel Production ausführen, wird das HTML innerhalb des Umgebungs-Tags für die Bereitstellung ausgegeben.

+0

danke. Das ist sehr hilfreich. – objectNotFound

+0

Ich bin froh zu helfen, wünschte nur, ich hätte nicht 2 Stunden gebraucht, um es herauszufinden. Ich empfehle alle dotnet cli command tutorials zu lesen, bevor ein Kernprojekt gestartet wird. Jetzt muss ich nur BundleConfig.Json und alle Tag-Helfer arbeiten und ich bin im Geschäft. –

+0

ok ... da dies alles brandneue Tech ist, schätze ich mehr Fragen und Selbstantworten ein dann? :) – objectNotFound

3

Wenn Sie ohne den Debugger ausgeführt werden (Strg + F5 oder im Menü Debug -> Ohne Debugger ausführen), wird die Anwendung weiterhin in IIS Express ausgeführt (vorausgesetzt, Sie verwenden die Standardeinstellungen). Sie können Änderungen vornehmen und den Browser aktualisieren, ohne ihn zu veröffentlichen oder neu zu starten.

Mit regulären IIS können Sie eine Website/Anwendung auf den Projektordner zeigen, und Sie müssen nie nach jeder Änderung veröffentlichen.

+0

Das Zeigen von IIS auf den Projektordner funktioniert nicht mit .NET Core. Der Projektordner enthält nicht die Laufzeit für DotNet Core und kann daher nicht geladen werden. Sie müssen IIS auf den veröffentlichten Dot Net Core-Ordner verweisen, den Sie mit DotNet Publish erhalten, und landen im Ordner bin \ debug. Dann können Sie keine Änderungen daran vornehmen. Sie müssen den Befehl dotnet erneut veröffentlichen Linie. Der IIS-Express-Teil ist jedoch gültig. –

+0

Wenn Sie dotnet run in einem Terminalfenster ausführen, wird das Problem gelöst. Sie können Änderungen an der Site vornehmen und müssen nur für kompilierte Codeänderungen neu erstellen. Ich denke auch, dass der Kestrel-Weg der beste Weg ist, weil er sicherstellt, dass Ihr Entwicklungsfluss zu den Cross-Plattform Jedi Ways passt. –

+0

Das Zeigen auf den Projektordner funktioniert, wenn Sie die richtige Konfiguration haben, die zugegebenermaßen nicht einfach ist. Stellen Sie beispielsweise sicher, dass AspNetCoreModule in IIS installiert ist, stellen Sie sicher, dass ApplicationPoolIdentity über Berechtigungen für den Projektordner verfügt. Stellen Sie sicher, dass web.config keine parametrisierten Einträge wie% LAUNCHER_PATH% enthält, die durch .NET ersetzt werden müssen. Ich habe einige der Probleme vergessen, die nötig waren, um es durchzuziehen. – OdeToCode