Laden...

Web Api Hosting - Internal Server Error

Erstellt von Rioma vor 8 Jahren Letzter Beitrag vor 8 Jahren 5.588 Views
R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren
Web Api Hosting - Internal Server Error

Hallo zusammen,

ich hätte nochmal eine Fragen zum Hosting unter IIS.

Ich habe über Visual Studio die Web Api veröffentlicht und im IIS eingehangen.

Ich bekomme allerdings beim Zugriff den Fehler

Fehlermeldung:
HTTP-Fehler 500.19 - Internal Server Error
Auf die angeforderte Seite kann nicht zugegriffen werden, da die zugehörigen Konfigurationsdaten für die Seite ungültig sind. HRESULT: 0X8007000D

Der Fehlercode ist einfach zu verstehen und HRESULT: 0X8007000D soll wohl heißen, dass die Web.config ein ungültiges XML Zeichen enthält.

Unter Visual Studio läuft allerdings alles Problemlos. Ich finde den Fehler daher einfach nicht.

Vielleicht könnte ja nochmal ein von euch ein Auge auf die Datei werfen:


<?xml version="1.0" encoding="utf-8"?>
<!--
  Weitere Informationen zum Konfigurieren Ihrer ASP.NET-Anwendung finden Sie unter
  http://go.microsoft.com/fwlink/?LinkId=301879
  -->
<configuration>
  <appSettings />
  <!--
    For a description of web.config changes see http://go.microsoft.com/fwlink/?LinkId=235367.

    The following attributes can be set on the <httpRuntime> tag.
      <system.Web>
        <httpRuntime targetFramework="4.5" />
      </system.Web>
  -->
  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
  <system.webServer>
    <handlers>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
    <rewrite>
      <rules>
        <rule name="AngularJS Routes" stopProcessing="true">
          <match url=".*" />
          <conditions logicalGrouping="MatchAll">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            <add input="{REQUEST_URI}" pattern="^/(api)" negate="true" />
            <add input="{REQUEST_URI}" pattern="^/(templates)" negate="true" />
            <add input="{REQUEST_URI}" pattern="^/(authtoken)" negate="true" />
          </conditions>
          <action type="Rewrite" url="/Index.html" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
  <connectionStrings>
    <add name="***" connectionString="***" />
  </connectionStrings>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Cors" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <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>
<system.data>
		<DbProviderFactories>
			<remove invariant="FirebirdSql.Data.FirebirdClient" />
			<add name="FirebirdClient Data Provider" invariant="FirebirdSql.Data.FirebirdClient" description=".NET Framework Data Provider for Firebird" type="FirebirdSql.Data.FirebirdClient.FirebirdClientFactory, FirebirdSql.Data.FirebirdClient" />
		</DbProviderFactories>
	</system.data>
</configuration>

Ich hoffe ihr habt einen Tipp.

Danke

16.807 Beiträge seit 2008
vor 8 Jahren

Es heisst nicht, dass es ein ungültiges Zeichen hat, sondern dass etwas enthalten ist, was nicht verarbeitet werden kann.
Das kann jetzt zB eine Referenz auf etwas sein, das einfach nicht existiert oder ein Typ-falscher Wert.

In 99% der Fälle ist es aber ein falscher Verweis.
Was mir auffällt:

* Warum muss Deine API Kenntnis über AngularJS Routes haben?
* Warum hast Du den CodeDom Eintrag gesetzt?
* Für Rewrite muss auch das passende Modul im IIS aktiviert sein

Vorgehenweise: kommentier alles aus, was nicht zum Standard gehört und füge es dann wieder nach und nach ein.
Dann weiß Du, welche XML Section den Fehler auslöst.

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

AngularJS dient als Frontend und die Web Api als Backend. Bei einem PageRefresh wurde auf der Serverseite nach der URL gesucht und natürlich nicht gefunden. Deswegen habe ich die Reweriteregeln eingebaut.

Der CodeDom Eintrag muss automatisch erzeugt worden sein. Ich war es auf jeden Fall nicht bewusst.

IIS Rewrite ist installiert und die Regeln werden in dem Modul aus der Webconfig auch richtig angezeigt.

Mir wird nun der folgende Fehler ausgegeben:

Dieser Konfigurationsabschnitt kann in diesem Pfad nicht verwendet werden. Dies ist der Fall, wenn der Abschnitt auf übergeordneter Ebene gesperrt ist. Die Sperrung erfolgt standardmäßig (overrideModeDefault="Deny") oder wird explizit mit einem location-Tag mit overrideMode="Deny" oder der Legacyeinstellung allowOverride="false" festgelegt.

Angegeben wird der handlers Bereich.


  20:   <system.webServer>
   21:     <handlers> <---- Rot hervorgehoben
   22:       <remove name="ExtensionlessUrlHandler-Integrated-4.0" />

Ich habe bereits einige Lösungsansätze im Internet gefunden und werde diese erstmal durchprobieren.

16.807 Beiträge seit 2008
vor 8 Jahren

Eine API als Backend sollte niemals wissen, was für ein Client, egal ob C#, Angular, PHP und Co der Aufrufer ist.
Hier also Abhängigkeiten zB zu Angular zu schaffen deutet deutlich darauf hin, dass etwas an der Struktur nicht stimmt. =)

Ich hab die befürchtung, dass Du das Projekt mit ASP.NET MVC, ASP.NET WebAPI und Angular mischst und es dadurch zu dieser engen Kopplung kommt.
Aus eigener Erfahrung und Schmerzen kann ich Dir sagen, dass das keine gute Idee ist.

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Die Solution besteht nur aus der Asp.Net Web Api + Angularjs.
Das heißt du würdest 2 Projekte daraus machen? (Frontend und Backend)
Falls ja, wie würde das Hosting unter IIS aussehen? Beide Projekte bekommen im IIS eine eigene "Seite" und eigenen Port?

Danke für deine Mühe

446 Beiträge seit 2004
vor 8 Jahren

Hallo,

hier gibt es natürlich mehrere Möglichkeiten dies umzusetzen. Aber WebApi und AngularJS auf zwei Projekte auf zu teilen ist schon mal gut. Ob du die AngularJS Anwendung dann auf einer ASP.NET MVC Seite "hostest" oder eine statische HTML Seite hinterlegst ist Geschmackssache.

Im Normalfall und der Einfachheitshalber legst du zum Deployen deine Projekte in der Default Web Site ab, oder du erstellst eine neue (was vor zu ziehen wäre). Diese Site ist dann im optimalen Fall über den Port 80 aufrufbar.

In dieser Site kannst du, dann die zwei Projekte bzw. Anwendungen hinterlegen. Würden die zwei Anwendungen unter verschiedenen Ports laufen hast du mit CORS zu tun, was du vermeiden möchtest.

Schaut mal im IRC vorbei:
Server: https://libera.chat/ ##chsarp

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Hallo und auch dir danke für deine Hilfe.

Ich werde die Anwendung nun auf 2 Projekte aufteilen. Nur nochmal um sicher zu gehen. Angularjs übernimmt das Routing Clientseitig. Ich hatte aber zum Beispiel bei einem Page refresh das Problem, dass die URL auf das Server Verzeichnis gemappt wurde und dort natürlich nichts gefunden wurde. Deswegen hatte ich die Web.config angepasst und es funktionierte auch ohne Probleme. Ist dies das falsche vorgehen, oder hatte ich das Problem nur, weil ich einen Fehler gemacht habe?

M
177 Beiträge seit 2009
vor 8 Jahren

Applikation mit AngularJS werden Clientseitig verarbeitet. Wenn du hier mit Rewrite Rules (ich wüsste auch gar nicht wie das gehen sollte - siehe hier) und anderen Workarounds versuchst bei einem Page Refresh die vorherige Seite wiederherzustellen, verlierst du genau diese Unabhängigkeit, da das ganze wieder Serverseitig geschieht.

Dass bei einer SPA bei einem Seiten refresh der Zustand verloren geht ist ein normales Verhalten. Du musst dieses mit JS bzw. AngularJS behandeln z.B. mit Cookies oder http://stackoverflow.com/questions/25040252/how-to-handle-prevent-browser-navigation-or-reload-in-angularjs usw. usf.
lg

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Hallo,

das Problem ist nicht, dass die Informationen verloren gehen, sondern es wird versucht die URL auf das Dateisystem zu mappen und das geht schief (404). Ich hätte sagen sollen, dass der HTML 5 Mode aktiviert ist, habe aber leider selber nicht daran gedacht. Ohne HTML 5 Mode würde soweit ich weiß nur die URL bis zum Hashbang auf das Dateisystem bezogen. Hier nachzulesen http://stackoverflow.com/questions/16569841/angularjs-html5-mode-reloading-the-page-gives-wrong-get-request

Ich werde die Anwendung nun erstmal in 2 Projekte teilen und versuchen das ganze unter dem IIS zu hosten. Bei Problemen melde ich mich nochmal.
Danke

16.807 Beiträge seit 2008
vor 8 Jahren

Ob du die AngularJS Anwendung dann auf einer ASP.NET MVC Seite "hostest" oder eine statische HTML Seite hinterlegst ist Geschmackssache.

Nein, das sehe ich nicht so.
Ich halte das nicht für Geschmackssache sondern ganz einfach falsch, denn es untergräbt den Sinn und Zweck einer Client-seitigen SPA.

Ja, man braucht ein Rewrite aber nur an dem Endpunkt, an dem AngularJS läuft.
Die API sollte immer einen eigenen Endpunkt haben und mit keiner Clienttechnologie vermischt sein.

Auch haben Ports relativ wenig mit CORS zutun (davon abgesehen sollten produktive Anwendungen keine Portangaben benötigen, da Benutzerunfreundlich); denn selbst unterschiedliche (Sub)Domains machen hier ein Strich durch die Rechnung.

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Danke dir auch nochmal für den Beitrag.

Wie genau würdest du denn das Hosting unter IIS aufbauen? Wenn du sagst zwei unterschiedliche Endpunkte, meinst du damit, das Frontend und Backend eine eigene Site im IIS bekommen? Demnach müsste die Web.Config nur im Frontend angepasst werden.
Oder verstehe ich dich falsch?

16.807 Beiträge seit 2008
vor 8 Jahren

Korrekt.

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Alles klar, dann wird es so umgesetzt. Danke euch.