ASP.NET Webbereitstellung mit Visual Studio: Problembehandlung

  • Artikel

von Tom Dykstra

Herunterladen des Starterprojekts

In dieser Tutorialreihe erfahren Sie, wie Sie mithilfe von Visual Studio 2012 oder Visual Studio 2010 eine ASP.NET Webanwendung für Azure App Service Web-Apps oder einen Hostinganbieter eines Drittanbieters bereitstellen (veröffentlichen). Informationen zur Reihe finden Sie im ersten Tutorial der Reihe.

Auf dieser Seite werden einige häufige Probleme beschrieben, die auftreten können, wenn Sie eine ASP.NET Webanwendung mithilfe von Visual Studio bereitstellen. Für jede werden eine oder mehrere mögliche Ursachen und entsprechende Lösungen bereitgestellt.

Die gezeigten Szenarien gelten sowohl für Azure als auch für Hostinganbieter von Drittanbietern. Weitere Informationen zur Problembehandlung von Web-Apps in Azure App Service finden Sie in den folgenden Ressourcen:

Serverfehler in der "/"-Anwendung : Aktuelle benutzerdefinierte Fehlereinstellungen verhindern, dass Details des Fehlers remote angezeigt werden

Szenario

Nachdem Sie eine Website auf einem Remotehost bereitgestellt haben, erhalten Sie eine Fehlermeldung, die die Einstellung customErrors in der Web.config-Datei erwähnt, aber nicht die tatsächliche Ursache des Fehlers angibt:

Server Error in '/' Application.
Runtime Error 

Description: An application error occurred on the server. The current custom error settings 
for this application prevent the details of the application error from being viewed remotely 
(for security reasons). It could, however, be viewed by browsers running on the local server 
machine. 

Details: To enable the details of this specific error message to be viewable on remote machines,
please create a <customErrors> tag within a "web.config" configuration file located in the
root directory of the current web application. This <customErrors> tag should then have its
"mode" attribute set to "Off".

Mögliche Ursache und Lösung

Standardmäßig zeigt ASP.NET nur dann detaillierte Fehlerinformationen an, wenn Ihre Webanwendung auf dem lokalen Computer ausgeführt wird. Im Allgemeinen möchten Sie keine detaillierten Fehlerinformationen anzeigen, wenn Ihre Webanwendung öffentlich über das Internet verfügbar ist, da Hacker diese Informationen möglicherweise verwenden können, um Sicherheitsrisiken in der Anwendung zu finden. Wenn Sie jedoch eine Website bereitstellen oder updates auf einer Website durchführen, geht manchmal etwas schief, und Sie müssen die tatsächliche Fehlermeldung erhalten.

Damit die Anwendung detaillierte Fehlermeldungen anzeigen kann, wenn sie auf dem Remotehost ausgeführt wird, bearbeiten Sie die Web.config-Datei, um den customErrors-Modus auszuschalten, stellen Sie die Anwendung erneut bereit, und führen Sie die Anwendung erneut aus:

  1. Wenn die Anwendung Web.config Datei ein customErrors-Element im system.web-Element enthält, ändern Sie das Mode-Attribut in "off". Fügen Sie andernfalls ein customErrors-Element im system.web-Element hinzu, wobei das mode-Attribut auf "off" festgelegt ist, wie im folgenden Beispiel gezeigt:

    <configuration>
  <system.web>
    <customErrors mode="off"/>
  </system.web>
</configuration>

  2. Stellen Sie die Anwendung bereit.

  3. Führen Sie die Anwendung aus, und wiederholen Sie alles, was Sie zuvor getan haben, was den Fehler verursacht hat. Nun können Sie sehen, was die tatsächliche Fehlermeldung ist.

  4. Wenn Sie den Fehler behoben haben, stellen Sie die ursprüngliche customErrors-Einstellung wieder her, und stellen Sie die Anwendung erneut bereit.

"ContosoUniversity" kann nicht erstellt/schattenkopiert werden, wenn diese Datei bereits vorhanden ist.

Szenario

Wenn Sie versuchen, ein Projekt in Visual Studio auszuführen, erhalten Sie eine Fehlerseite mit einer Meldung wie im folgenden Beispiel:

Serverfehler in Anwendung '/'. "ContosoUniversity" kann nicht erstellt/schattenkopiert werden, wenn diese Datei bereits vorhanden ist.

Mögliche Ursache und Lösung

Warten Sie eine Minute, und aktualisieren Sie den Browser, oder kompilieren Sie die Website neu, und versuchen Sie, sie erneut auszuführen.

Der Zugriff wird auf einer Webseite verweigert, die SQL Server Compact

Szenario

Wenn Sie einen Standort bereitstellen, der SQL Server Compact verwendet, und Sie eine Seite am bereitgestellten Standort ausführen, der auf die Datenbank zugreift, wird die folgende Fehlermeldung angezeigt:

Zugriff verweigert.“ (Ausnahme von HRESULT: 0x80070005 (E_ACCESSDENIED))“

Mögliche Ursache und Lösung

Das NETWORK SERVICE-Konto auf dem Server muss native SQL Service Compact-Binärdateien lesen können, die sich im Ordner bin\amd64 oder bin\x86 befinden, verfügt aber nicht über Leseberechtigungen für diese Ordner. Legen Sie die Leseberechtigung für NETWORK SERVICE für den Ordner bin fest, und stellen Sie sicher, dass Sie die Berechtigungen auf Unterordner erweitern.

Die Konfigurationsdatei kann aufgrund unzureichender Berechtigungen nicht gelesen werden.

Szenario

Wenn Sie auf die Schaltfläche Veröffentlichen von Visual Studio klicken, um eine Anwendung in IIS auf Ihrem lokalen Computer bereitzustellen, tritt bei der Veröffentlichung ein Fehler auf, und im Fenster Ausgabe wird eine Fehlermeldung ähnlich der folgenden angezeigt:

Fehler beim Lesen der IIS-Konfigurationsdatei "MACHINE/REDIRECTION". Die Identität, die diesen Vorgang ausführte, war ... Fehler: Die Konfigurationsdatei kann aufgrund unzureichender Berechtigungen nicht gelesen werden.

Mögliche Ursache und Lösung

Wenn Sie die Veröffentlichung mit einem Klick in IIS auf Ihrem lokalen Computer verwenden möchten, müssen Sie Visual Studio mit Administratorberechtigungen ausführen. Schließen Sie Visual Studio, und starten Sie es mit Administratorberechtigungen neu.

Es konnte keine Verbindung mit dem Zielcomputer hergestellt werden... Verwenden des angegebenen Prozesses

Szenario

Wenn Sie zum Bereitstellen einer Anwendung auf die Schaltfläche Veröffentlichen in Visual Studio klicken, tritt bei der Veröffentlichung ein Fehler auf, und im Fenster Ausgabe wird eine Fehlermeldung ähnlich der folgenden angezeigt:

Web deployment task failed.(Could not connect to the destination computer ("<server URL>") using the specified process
("The Web Management Service"). This can happen if a proxy server is interrupting communication with the destination server. 
Disable the proxy server and try again.) ... The remote server returned an error: (502) Bad Gateway.

Mögliche Ursache und Lösung

Ein Proxyserver unterbricht die Kommunikation mit dem Zielserver. Wählen Sie im Windows-Systemsteuerung oder in internet Explorer die Option Internetoptionen und dann die Registerkarte Verbindungen aus. Klicken Sie im Dialogfeld Interneteigenschaften auf LAN-Einstellungen. Deaktivieren Sie im Dialogfeld Einstellungen für lokales Netzwerk (LAN) das Kontrollkästchen Einstellungen automatisch erkennen . Klicken Sie dann erneut auf die Schaltfläche Veröffentlichen.

Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Systemadministrator, um zu ermitteln, was mit Proxy- oder Firewalleinstellungen geschehen kann. Das Problem tritt auf, weil Web Deploy einen nicht standardmäßigen Port für die Bereitstellung des Webverwaltungsdiensts verwendet (8172); Für andere Verbindungen verwendet Web Deploy Port 80. Wenn Sie die Bereitstellung bei einem Hostinganbieter eines Drittanbieters durchführen, verwenden Sie in der Regel den Webverwaltungsdienst.

Der .NET 4.0-Standardanwendungspool ist nicht vorhanden.

Szenario

Wenn Sie eine Anwendung bereitstellen, die die .NET Framework 4 erfordert, wird die folgende Fehlermeldung angezeigt:

Der .NET 4.0-Standardanwendungspool ist nicht vorhanden, oder die Anwendung konnte nicht hinzugefügt werden. Überprüfen Sie, ob ASP.NET 4.0 auf diesem Computer installiert ist.

Mögliche Ursache und Lösung

ASP.NET 4 ist in IIS nicht installiert. Wenn es sich bei dem Server, auf dem Sie die Bereitstellung durchführen, um Ihren Entwicklungscomputer handelt, auf dem Visual Studio 2010 installiert ist, wird ASP.NET 4 auf dem Computer installiert, aber möglicherweise nicht in IIS installiert. Öffnen Sie auf dem Server, auf dem Sie die Bereitstellung durchführen, eine Eingabeaufforderung mit erhöhten Rechten, und installieren Sie ASP.NET 4 in IIS, indem Sie die folgenden Befehle ausführen:

cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru

Möglicherweise müssen Sie auch die .NET Framework Version des Standardanwendungspools manuell festlegen. Weitere Informationen finden Sie im Tutorial Bereitstellen in IIS als Testumgebung in dieser Reihe.

Das Format der Initialisierungszeichenfolge entspricht nicht der Spezifikation ab Index 0.

Szenario

Wenn Sie eine Seite ausführen, die auf die Datenbank zugreift, erhalten Sie nach der Bereitstellung einer Anwendung mithilfe der Veröffentlichung mit einem Klick die folgende Fehlermeldung:

Das Format der Initialisierungszeichenfolge entspricht nicht der Spezifikation ab Index 0.

Mögliche Ursache und Lösung

Öffnen Sie die Web.config-Datei auf der bereitgestellten Website, und überprüfen Sie, ob die Werte der Verbindungszeichenfolge mit $(ReplaceableToken_beginnen, wie im folgenden Beispiel gezeigt:

<connectionStrings>
  <add name="DefaultConnection" connectionString="$(ReplaceableToken_DefaultConnection-Web.config Connection String_0)" providerName="System.Data.SqlServerCe.4.0" />
  <add name="SchoolContext" connectionString="$(ReplaceableToken_SchoolContext-Web.config Connection String_0)" providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>

Wenn die Verbindungszeichenfolgen wie in diesem Beispiel aussehen, bearbeiten Sie die Projektdatei, und fügen Sie dem PropertyGroup-Element die folgende Eigenschaft hinzu, die für alle Buildkonfigurationen gilt:

<AutoParameterizationWebConfigConnectionStrings>False</AutoParameterizationWebConfigConnectionStrings>

Stellen Sie dann die Anwendung erneut bereit.

Interner HTTP 500-Serverfehler

Szenario

Wenn Sie den bereitgestellten Standort ausführen, wird die folgende Fehlermeldung ohne spezifische Informationen angezeigt, die die Ursache des Fehlers angeben:

HTTP-Fehler 500: Interner Serverfehler.

Mögliche Ursache und Lösung

Es gibt viele Ursachen für 500 Fehler, aber eine mögliche Ursache, wenn Sie diese Tutorials befolgen, ist, dass Sie ein XML-Element an der falschen Stelle in einer der Web.config Transformationsdateien platzieren. Beispielsweise erhalten Sie diesen Fehler, wenn Sie die Transformation, die ein <Location-Element> einfügt, unter <system.web> anstatt direkt unter <der Konfiguration> platzieren. Sie können das Feature Web.config Transformationsvorschau verwenden, um zu überprüfen, ob Transformationen wie beabsichtigt funktionieren. Die Lösung, wenn Sie eine falsch codierte Transformation finden, besteht darin, die Transformationsdatei zu korrigieren und erneut bereitzustellen. Wenn ein Fehler nicht offensichtlich ist, versuchen Sie, Transformationen auszukommentieren und erneut bereitzustellen, um zu ermitteln, welche der Fehler 500 verursacht.

Interner HTTP 500.21-Serverfehler

Szenario

Wenn Sie den bereitgestellten Standort ausführen, wird die folgende Fehlermeldung angezeigt:

HTTP-Fehler 500.21: Interner Serverfehler. Der Handler "PageHandlerFactory-Integrated" enthält ein ungültiges Modul "ManagedPipelineHandler" in der Modulliste.

Mögliche Ursache und Lösung

Der von Ihnen bereitgestellte Standort hat ziele ASP.NET 4, aber ASP.NET 4 ist nicht in IIS auf dem Server registriert. Öffnen Sie auf dem Server eine Eingabeaufforderung mit erhöhten Rechten, und registrieren Sie ASP.NET 4, indem Sie die folgenden Befehle ausführen:

cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru

Möglicherweise müssen Sie auch die .NET Framework Version des Standardanwendungspools manuell festlegen. Weitere Informationen finden Sie im Tutorial Bereitstellen in IIS als Testumgebung in dieser Reihe.

Fehler beim Öffnen der SQL Server Express-Datenbank in App_Data

Szenario

Sie haben die Verbindungszeichenfolge für dieWeb.configDatei aktualisiert, damit sie auf eine SQL Server Express-Datenbank als MDF-Datei im Ordner App_Data verweist. Beim ersten Ausführen der Anwendung wird die folgende Fehlermeldung angezeigt:

System.Data.SqlClient.SqlException: Die von der Anmeldung angeforderte Datenbank "DatabaseName" kann nicht geöffnet werden. Fehler bei der Anmeldung.

Mögliche Ursache und Lösung

Der Name der MDF-Datei kann nicht mit dem Namen einer SQL Server Express Datenbank übereinstimmen, die jemals auf Ihrem Computer vorhanden war, auch wenn Sie die MDF-Datei der zuvor vorhandenen Datenbank gelöscht haben. Ändern Sie den Namen der MDF-Datei in einen Namen, der noch nie als Datenbankname verwendet wurde, und ändern Sie die Web.config-Datei , um den neuen Namen zu verwenden. Alternativ können Sie SQL Server Management Studio Express verwenden, um bereits vorhandene SQL Server Express Datenbanken zu löschen.

Modellkompatibilität kann nicht überprüft werden

Szenario

Sie haben die verbindungszeichenfolge für dieWeb.configDatei aktualisiert, um auf eine neue SQL Server Express-Datenbank zu verweisen. Beim ersten Ausführen der Anwendung wird die folgende Fehlermeldung angezeigt:

Die Modellkompatibilität kann nicht überprüft werden, da die Datenbank keine Modellmetadaten enthält. Stellen Sie sicher, dass IncludeMetadataConvention den DbModelBuilder-Konventionen hinzugefügt wurde.

Mögliche Ursache und Lösung

Wenn der Datenbankname, den Sie in die Web.config-Datei eingefügt haben, jemals zuvor auf Ihrem Computer verwendet wurde, ist möglicherweise bereits eine Datenbank mit einigen Tabellen vorhanden. Wählen Sie einen neuen Namen aus, der zuvor noch nicht auf Ihrem Computer verwendet wurde, und ändern Sie die Web.config Datei so, dass sie auf die Verwendung dieses neuen Datenbanknamens verweist. Alternativ können Sie SQL Server Express Hilfsprogramm oder SQL Server Management Studio Express verwenden, um die vorhandene Datenbank zu löschen.

SQL-Fehler, wenn ein Skript versucht, Benutzer oder Rollen zu erstellen

Szenario

Sie verwenden die datenbankbasierte Bereitstellung, die auf der Registerkarte SQL-Paket/SQL veröffentlichen konfiguriert ist. SQL-Skripts, die während der Bereitstellung ausgeführt werden, umfassen befehle "Benutzer erstellen" oder "Rolle erstellen", und die Skriptausführung schlägt fehl, wenn diese Befehle ausgeführt werden. Möglicherweise werden ausführlichere Meldungen angezeigt, z. B. die folgenden:

The approximate location of the error was between lines '1' and '3' of the script. 
The verbose log may have more information about the error. The command started with:
CREATE USER [user2] FOR LOGIN [user2] WITH DEFAULT
Error: User does not have permission to perform this action.

Wenn dieser Fehler auftritt, wenn Sie die Datenbankbereitstellung im Assistenten zum Veröffentlichen von Web und nicht auf der Registerkarte SQL-Paket/SQL veröffentlichen konfiguriert haben, erstellen Sie im Konfigurations - und Bereitstellungsforum einen Thread, und die Lösung wird dieser Problembehandlungsseite hinzugefügt.

Mögliche Ursache und Lösung

Das Benutzerkonto, das Sie für die Bereitstellung verwenden, verfügt nicht über die Berechtigung zum Erstellen von Benutzern oder Rollen. Beispielsweise kann das Hostingunternehmen dem Benutzerkonto, das es für Sie eingerichtet hat, die Rollen db_datareader, db_datawriter und db_ddladmin zuweisen. Diese sind ausreichend, um die meisten Datenbankobjekte zu erstellen, aber nicht zum Erstellen von Benutzern oder Rollen. Eine Möglichkeit, den Fehler zu vermeiden, besteht darin, Benutzer und Rollen von der Datenbankbereitstellung auszuschließen. Dazu bearbeiten Sie das PreSource-Element für das automatisch generierte Skript der Datenbank, sodass es die folgenden Attribute enthält:

CopyAllUsers=false, CopyAllRoles=false

Informationen zum Bearbeiten des PreSource-Elements in der Projektdatei finden Sie unter Vorgehensweise: Bearbeiten von Bereitstellungseinstellungen in der Projektdatei. Wenn sich die Benutzer oder Rollen in Ihrer Entwicklungsdatenbank in der Zieldatenbank befinden müssen, wenden Sie sich an Ihren Hostinganbieter, um Unterstützung zu erhalten.

SQL Server Timeoutfehler beim Ausführen benutzerdefinierter Skripts während der Bereitstellung

Szenario

Sie haben benutzerdefinierte SQL-Skripts angegeben, die während der Bereitstellung ausgeführt werden sollen, und wenn Web Deploy sie ausführt, tritt ein Timeout auf.

Mögliche Ursache und Lösung

Das Ausführen mehrerer Skripts mit unterschiedlichen Transaktionsmodi kann zu Timeoutfehlern führen. Standardmäßig werden automatisch generierte Skripts in einer Transaktion ausgeführt, benutzerdefinierte Skripts hingegen nicht. Wenn Sie auf der Registerkarte SQL-Paket/SQL veröffentlichen die Option Daten und/oder Schema aus einer vorhandenen Datenbank abrufen auswählen und ein benutzerdefiniertes SQL-Skript hinzufügen, müssen Sie die Transaktionseinstellungen für einige Skripts ändern, sodass alle Skripts dieselben Transaktionseinstellungen verwenden. Weitere Informationen finden Sie unter Vorgehensweise: Bereitstellen einer Datenbank mit einem Webanwendungsprojekt.

Wenn Sie die Transaktionseinstellungen so konfiguriert haben, dass alle identisch sind, dieser Fehler jedoch weiterhin angezeigt wird, besteht eine mögliche Problemumgehung darin, die Skripts separat auszuführen. Deaktivieren Sie im Raster Datenbankskripts auf der Registerkarte SQL packen/veröffentlichen das Kontrollkästchen Einschließen für das Skript, das den Timeoutfehler verursacht, und veröffentlichen Sie dann das Projekt. Wechseln Sie dann zurück zum Raster Datenbankskripts , aktivieren Sie das Kontrollkästchen Einschließen dieses Skripts, und deaktivieren Sie die Kontrollkästchen Einschließen für die anderen Skripts. Veröffentlichen Sie dann das Projekt erneut. Wenn Sie dieses Mal veröffentlichen, wird nur das ausgewählte benutzerdefinierte Skript ausgeführt.

Streamdaten des Websitemanifests sind noch nicht verfügbar

Szenario

Wenn Sie ein Paket mithilfe der Datei deploy.cmd mit der Option t (test) installieren, wird die folgende Fehlermeldung angezeigt:

Fehler: Die Datenstromdaten von "sitemanifest/dbFullSql[@path='C:\TEMP\AdventureWorksGrant.sql']/sqlScript" sind noch nicht verfügbar.

Mögliche Ursache und Lösung

Die Fehlermeldung bedeutet, dass der Befehl keinen Testbericht erstellen kann. Der Befehl kann jedoch ausgeführt werden, wenn Sie die Option y (tatsächliche Installation) verwenden. Die Meldung gibt nur an, dass ein Problem beim Ausführen des Befehls im Testmodus vorliegt.

Diese Anwendung erfordert ManagedRuntimeVersion v4.0.

Szenario

Wenn Sie versuchen, die Bereitstellung durchzuführen, wird die folgende Fehlermeldung angezeigt:

Für den Anwendungspool, den Sie verwenden möchten, ist die Eigenschaft "managedRuntimeVersion" auf "v2.0" festgelegt. Für diese Anwendung ist "v4.0" erforderlich.

Mögliche Ursache und Lösung

ASP.NET 4 ist in IIS nicht installiert. Wenn es sich bei dem Server, auf dem Sie die Bereitstellung durchführen, um Ihren Entwicklungscomputer handelt, auf dem Visual Studio 2010 installiert ist, wird ASP.NET 4 auf dem Computer installiert, aber möglicherweise nicht in IIS installiert. Öffnen Sie auf dem Server, auf dem Sie die Bereitstellung durchführen, eine Eingabeaufforderung mit erhöhten Rechten, und installieren Sie ASP.NET 4 in IIS, indem Sie die folgenden Befehle ausführen:

cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –i

Microsoft.Web.Deployment.DeploymentProviderOptions kann nicht umgewandelt werden

Szenario

Wenn Sie ein Paket bereitstellen, wird die folgende Fehlermeldung angezeigt:

Ein Objekt vom Typ "Microsoft.Web.Deployment.DeploymentProviderOptions" kann nicht in "Microsoft.Web.Deployment.DeploymentProviderOptions" umgewandelt werden.

Mögliche Ursache und Lösung

Sie versuchen, die Bereitstellung über den IIS-Manager über die Web Deploy 1.1-Benutzeroberfläche auf einem Server bereitzustellen, auf dem Web Deploy 2.0 installiert ist. Wenn Sie das IIS-Remoteverwaltungstool für die Bereitstellung verwenden, indem Sie ein Paket importieren, aktivieren Sie das Dialogfeld Neue Features verfügbar , wenn Sie die Verbindung herstellen. (Dieses Dialogfeld wird möglicherweise nur einmal angezeigt, wenn die Verbindung zum ersten Mal hergestellt wird. Um die Verbindung zu löschen und von vorne zu beginnen, schließen Sie den IIS-Manager, und starten Sie ihn erneut, indem Sie an der Eingabeaufforderung inetmgr /reset eingeben.) Wenn eines der aufgeführten Features die Web Deploy-Benutzeroberfläche ist und eine Versionsnummer kleiner als 8 ist, sind auf dem Server, auf dem Sie bereitstellen, möglicherweise sowohl die Versionen 1.1 als auch 2.0 von Web Deploy installiert. Für die Bereitstellung von einem Client, auf dem 2.0 installiert ist, muss auf dem Server nur Web Deploy 2.0 installiert sein. Sie müssen sich an Ihren Hostinganbieter wenden, um dieses Problem zu beheben.

Die nativen Komponenten von SQL Server Compact können nicht geladen werden.

Szenario

Wenn Sie den bereitgestellten Standort ausführen, wird die folgende Fehlermeldung angezeigt:

Die nativen Komponenten von SQL Server Compact können nicht geladen werden, die dem ADO.NET Anbieter von Version 8482 entsprechen. Installieren Sie die richtige Version von SQL Server Compact. Weitere Informationen finden Sie im KB-Artikel 974247.

Mögliche Ursache und Lösung

Der bereitgestellte Standort verfügt nicht über amd64 - und x86-Unterordner mit den nativen Assemblys im Ordner bin der Anwendung. Auf einem Computer, auf dem SQL Server Compact installiert ist, befinden sich die nativen Assemblys unter C:\Programme\Microsoft SQL Server Compact Edition\v4.0\Private. Die beste Möglichkeit, die richtigen Dateien in die richtigen Ordner in einem Visual Studio-Projekt zu bringen, ist die Installation des NuGet SqlServerCompact-Pakets. Bei der Paketinstallation wird ein Skript nach dem Build hinzugefügt, um die nativen Assemblys in amd64 und x86 zu kopieren. Damit diese bereitgestellt werden können, müssen Sie sie jedoch manuell in das Projekt aufnehmen. Weitere Informationen finden Sie im Tutorial Bereitstellen von SQL Server Compact.

Fehler "Pfad ist ungültig" nach dem Bereitstellen einer Entity Framework Code First-Anwendung

Szenario

Sie stellen eine Anwendung bereit, die Entity Framework Code First-Migrationen und ein DBMS verwendet, z. B. SQL Server Compact, das die Datenbank in einer Datei im Ordner App_Data speichert. Sie haben Code First-Migrationen so konfiguriert, dass die Datenbank nach der ersten Bereitstellung erstellt wird. Wenn Sie die Anwendung ausführen, erhalten Sie eine Fehlermeldung wie im folgenden Beispiel:

Der Pfad ist nicht gültig. Überprüfen Sie das Verzeichnis auf die Datenbank. [Path = c:\inetpub\wwwroot\App_Data\DatabaseName.sdf ]

Mögliche Ursache und Lösung

Code First versucht, die Datenbank zu erstellen, aber der Ordner App_Data ist nicht vorhanden. Entweder hatten Sie bei der Bereitstellung keine Dateien im Ordner App_Data, oder Sie haben App_Data ausschließen auf der Registerkarte Paket/Web veröffentlichen des Project-Eigenschaftenfenster ausgewählt. Der Bereitstellungsprozess erstellt keinen Ordner auf dem Server, wenn keine Dateien im Ordner vorhanden sind, die auf den Server kopiert werden sollen. Wenn Sie die Datenbank bereits am Standort eingerichtet haben, werden beim Bereitstellungsprozess die Dateien und der ordner App_Data selbst gelöscht, wenn Sie zusätzliche Dateien am Ziel entfernen im Veröffentlichungsprofil ausgewählt haben. Um das Problem zu beheben, legen Sie eine Platzhalterdatei wie z. B. eine .txt-Datei in den Ordner App_Data , stellen Sie sicher, dass Sie nicht ausschließen App_Data ausgewählt haben, und stellen Sie erneut bereit.

"COM-Objekt, das von seinem zugrunde liegenden RCW getrennt wurde, kann nicht verwendet werden."

Szenario

Sie haben erfolgreich die Veröffentlichung mit einem Klick verwendet, um Ihre Anwendung bereitzustellen, und dann erhalten Sie diesen Fehler:

Fehler beim Webbereitstellungstask. (Die Anforderung an die Remote-Agent-URL "<https://serverurl.com/msdeploy.axd?site=sitename>" konnte nicht abgeschlossen werden.)
Die Anforderung an die Remote-Agent-URL "<https://url/msdeploy.axd?site=sitename>" konnte nicht abgeschlossen werden.
Die Anforderung wurde abgebrochen: Die Anforderung wurde abgebrochen.
Com-Objekt, das von seinem zugrunde liegenden RCW getrennt wurde, kann nicht verwendet werden.

Mögliche Ursache und Lösung

Das Schließen und Neustarten von Visual Studio ist in der Regel alles, was erforderlich ist, um diesen Fehler zu beheben.

Fehler bei der Bereitstellung, weil für die Veröffentlichung verwendete Benutzeranmeldeinformationen keine setACL-Autorität besitzen

Szenario

Bei der Veröffentlichung tritt ein Fehler auf, der darauf hinweist, dass Sie nicht über die Berechtigung zum Festlegen von Ordnerberechtigungen verfügen (das verwendete Benutzerkonto verfügt nicht über die Berechtigung setACL).

Mögliche Ursache und Lösung

Standardmäßig legt Visual Studio Leseberechtigungen für den Stammordner der Website und Schreibberechtigungen für den Ordner App_Data fest. Wenn Sie wissen, dass die Standardberechtigungen für Websiteordner korrekt sind und nicht festgelegt werden müssen, deaktivieren Sie dieses Verhalten, indem Sie includeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> der Veröffentlichungsprofildatei (um sich auf ein einzelnes Profil auswirken) oder der Datei wpp.targets (um alle Profile zu beeinflussen) hinzufügen<. Informationen zum Bearbeiten dieser Dateien finden Sie unter Vorgehensweise: Bearbeiten von Bereitstellungseinstellungen in Profildateien (PUBXML).

Fehler bei Zugriff verweigert, wenn die Anwendung versucht, in einen Anwendungsordner zu schreiben

Szenario

Ihre Anwendungsfehler, wenn sie versucht, eine Datei in einem der Anwendungsordner zu erstellen oder zu bearbeiten, da sie keine Schreibberechtigung für diesen Ordner hat.

Mögliche Ursache und Lösung

Standardmäßig legt Visual Studio Leseberechtigungen für den Stammordner der Website und Schreibberechtigungen für den Ordner App_Data fest. Wenn Ihre Anwendung Schreibzugriff auf einen Unterordner benötigt, können Sie Berechtigungen für diesen Ordner festlegen, wie in den Tutorials Festlegen von Ordnerberechtigungen und Bereitstellen in der Produktionsumgebung in dieser Reihe gezeigt. Wenn Ihre Anwendung Schreibzugriff auf den Stammordner der Website benötigt, müssen Sie verhindern, dass sie den schreibgeschützten Zugriff auf den Stammordner festlegt, indem Sie includeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> zur Veröffentlichungsprofildatei (um sich auf ein einzelnes Profil auswirken) oder der Datei wpp.targets (um alle Profile zu beeinflussen) hinzufügen<. Informationen zum Bearbeiten dieser Dateien finden Sie unter Vorgehensweise: Bearbeiten von Bereitstellungseinstellungen in Profildateien (PUBXML).

Konfigurationsfehler: targetFramework-Attribut verweist auf eine Version, die höher als die installierte Version des .NET Framework

Szenario

Sie haben erfolgreich ein Webprojekt veröffentlicht, das auf ASP.NET 4.5 abzielt, aber wenn Sie die Anwendung ausführen (wobei der customErrors-Modus in der Web.config-Datei auf "off" festgelegt ist), erhalten Sie den folgenden Fehler:

Das Attribut 'targetFramework' im <Kompilierungselement> der Web.config-Datei wird nur für Die Zielversion 4.0 und höher des .NET Framework verwendet (z. B. "<compilation targetFramework="4.0">). Das Attribut "targetFramework" verweist derzeit auf eine Version, die höher ist als die installierte Version des .NET Framework. Geben Sie eine gültige Zielversion des .NET Framework an, oder installieren Sie die erforderliche Version der .NET Framework.

Im Feld Quellfehler der Fehlerseite wird die folgende Zeile aus Web.config als Fehlerursache hervorgehoben:

<compilation targetFramework="4.5" />

Mögliche Ursache und Lösung

Der Server unterstützt ASP.NET 4.5 nicht. Wenden Sie sich an den Hostinganbieter, um zu ermitteln, wann und ob Unterstützung für ASP.NET 4.5 hinzugefügt werden kann. Wenn das Upgrade des Servers keine Option ist, müssen Sie stattdessen ein Webprojekt bereitstellen, das auf ASP.NET 4 oder früher ausgerichtet ist.

Wenn Sie ein ASP.NET 4 oder früheren Webprojekt auf demselben Ziel bereitstellen, aktivieren Sie auf der Registerkarte Einstellungen des Assistenten zum Veröffentlichen von Web das Kontrollkästchen Zusätzliche Dateien am Ziel entfernen. Wenn Sie nicht zusätzliche Dateien am Ziel entfernen auswählen, erhalten Sie weiterhin die Seite Konfigurationsfehler.

Die Projekteigenschaftenfenster enthalten eine Dropdownliste zielframework, aber Sie können dieses Problem nicht beheben, indem Sie dies von .NET Framework 4.5 in .NET Framework 4 ändern. Wenn Sie das Zielframework in eine frühere Frameworkversion ändern, enthält das Projekt weiterhin Verweise auf die Assemblys der späteren Frameworkversion und wird nicht ausgeführt. Sie müssen diese Verweise manuell ändern oder ein neues Projekt erstellen, das auf .NET Framework 4 oder früher ausgerichtet ist. Weitere Informationen finden Sie unter .NET Framework Targeting für Websites.

Fehler bei mittlerer Vertrauensstellung

Szenario

Wenn Sie Ihre Anwendung in der Produktion ausführen, wird ein Fehler im Zusammenhang mit mittlerer Vertrauensstellung angezeigt.

Mögliche Ursache und Lösung

Viele Hostinganbieter von Drittanbietern führen Ihre Website mit mittlerer Vertrauenswürdigkeit aus, was bedeutet, dass es einige Dinge gibt, die sie nicht tun darf. Beispielsweise kann der Anwendungscode nicht auf die Windows-Registrierung zugreifen und keine Dateien lesen oder schreiben, die sich außerhalb der Ordnerhierarchie Ihrer Anwendung befinden. Standardmäßig wird Ihre Anwendung auf Ihrem lokalen Computer mit voller Vertrauenswürdigkeit ausgeführt. Dies bedeutet, dass die Anwendung möglicherweise in der Lage ist, Dinge zu tun, die bei der Bereitstellung in der Produktion fehlschlagen würden.

Sie können die Anwendung so konfigurieren, dass sie in der lokalen IIS-Umgebung mit mittlerer Vertrauensstellung ausgeführt wird, um Probleme zu beheben. Öffnen Sie dazu die Anwendung Web.config Datei, und fügen Sie ein Vertrauenselement im system.web-Element hinzu, wie in diesem Beispiel gezeigt.

<configuration>
  <!-- Settings -->
  <system.web>
    <trust level="Medium" />
    <!-- Settings -->
  </system.web>
</configuration>

Die Anwendung wird nun in IIS auch auf Ihrem lokalen Computer mit mittlerer Vertrauensstellung ausgeführt.

Tun Sie dies nicht, wenn Sie in Azure App Service bereitstellen, da Azure keine mittlere Vertrauensstellung erfordert. Zum Zeitpunkt, zu dem dieses Tutorial im Februar 2012 geschrieben wird, führt die Verwendung dieser Methode zur Ausführung Ihrer Anwendung mit mittlerer Vertrauenswürdigkeit zu einem Fehler in Azure.

Wenn Sie Entity Framework Code First-Migrationen verwenden und bei einem Hostinganbieter bereitstellen, der Ihre Anwendung mit mittlerer Vertrauensstellung ausführt, stellen Sie sicher, dass Version 5.0 oder höher installiert ist. In Entity Framework Version 4.3 erfordert Migrationen volle Vertrauenswürdigkeiten, um das Datenbankschema zu aktualisieren.

HTTP 404.17 Fehler nicht gefunden

Szenario

Wenn Sie den bereitgestellten Standort auf Ihrem Entwicklungscomputer in IIS ausführen, wird die folgende Fehlermeldung angezeigt, dass der Server Default.aspx nicht verarbeiten kann:

HTTP-Fehler 404.17 – Nicht gefunden

Der angeforderte Inhalt scheint ein Skript zu sein und wird nicht vom Handler für statische Dateien bereitgestellt.

Mögliche Ursache und Lösung

ASP.NET 4.5 ist möglicherweise nicht auf Ihrem Computer installiert. Sehen Sie sich die Schritte im Tutorial Bereitstellen in IIS als Testumgebung in dieser Reihe an, in denen erläutert wird, wie Sie ASP.NET 4.5 installieren.

Zurück