2012-04-03 9 views
8

Ich habe Probleme bei der Bereitstellung einer ASP-Webanwendung auf HostMySite. Die Anwendung wurde zuvor ohne Probleme auf ihren Servern auf verschiedenen Plattformen bereitgestellt. Für die aktuelle Domäne und den Server bekomme ich jedoch weiterhin den Serverfehler unten.Warum versucht meine ASP-Webanwendung, in C: Windows Microsoft.NET Framework64 v4.0.30319 temporäre ASP.NET-Dateien zu schreiben?

Serverfehler in '/ PropertyManagement' Anwendung. Die aktuelle Identität (ADSAFESECUREWEB \ C116018-fhmonlinea) hat keinen Schreibzugriff auf "C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporäre ASP.NET-Dateien". Beschreibung: Bei der Ausführung der aktuellen Webanforderung ist eine nicht behandelte Ausnahme aufgetreten. Bitte überprüfen Sie die Stack-Trace für weitere Informationen über den Fehler und wo es aus dem Code stammt.

Ausnahmedetails: System.Web.HttpException: Die aktuelle Identität (ADSAFESECUREWEB \ C116018-fhmonlinea) hat keinen Schreibzugriff auf 'C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporäre ASP.NET-Dateien ".

Quellfehler:

Eine nicht behandelte Ausnahme wurde während der Ausführung der aktuellen Webanfrage generiert. Informationen über den Ursprung und den Ort der Ausnahme können anhand der folgenden Ausnahme-Stack-Trace identifiziert werden. Ich weiß, dass der Code nicht explizit versucht, in das temporäre Verzeichnis von .NET zu schreiben, aber ich habe mich gefragt, ob die Anwendung dieses Verzeichnis während der Laufzeit irgendwie benutzt. Der Host sagt mir immer wieder, dass ich meine Anwendung so konfigurieren muss, dass sie das temporäre Verzeichnis nicht verwendet, da sie keinen Lese-/Schreibzugriff darauf bietet. Kann mir bitte jemand sagen, warum meine Anwendung versucht, dieses Verzeichnis zu verwenden und was ich tun kann, um es so zu konfigurieren, dass es ein anderes Verzeichnis verwendet, auf das ich Zugriff habe. Ich bin neu in ASP Entwicklung und brauche Hilfe. Vielen Dank!

Stack Trace:

[Httpexception (0x80004005): Die aktuelle Identität (ADSAFESECUREWEB \ C116018-fhmonlinea) keinen Schreibzugriff auf ‚C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporary ASP.NET Files'.] System.Web.HttpRuntime.SetUpCodegenDirectory (CompilationSection compilationSection) 11650831 System.Web.HttpRuntime.HostingInit (HostingEnvironmentFlags hostingFlags, Policypolicy, Exception appDomainCreationException) +323

[Httpexception (0x80004005) : Die aktuelle Identität (ADSAFESECUREWEB \ C116018-fhmonlinea) hat keinen Schreibzugriff auf 'C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporary ASP.NET Files'.] System.Web.HttpRuntime.FirstRequestInit (Httpcontext context) 11612256 System.Web.HttpRuntime.EnsureFirstRequestInit (Httpcontext context) +141 System.Web .HttpRuntime.ProcessRequestNotificationPrivate (IIS7WorkerRequest wr, HttpContext-Kontext) +4842149

Versionsinformation: Microsoft .NET Framework Version: 4.0.30319; ASP.NET Version: 4.0.30319.1

Antwort

23

Die CLR kopiert alle Ihre Assemblys in dieses Verzeichnis und kompiliert Ihre .aspx/.asmx/etc-Dateien und legt die kompilierte Version in temporäre ASP.NET-Dateien.

Dies muss beschreibbar sein, damit Ihre Site zur Laufzeit kompiliert werden kann.

Edit: Hier ist an MSDN article es zu erklären.

Wie in den Kommentaren diskutiert, wenn der Anbieter Sie in dieses Verzeichnis schreiben zu lassen, weigert sich, können Sie es, indem sie die folgenden in Ihrem web.config, außer Kraft setzen kann ‚system.web‘ Abschnitt:

<compilation tempDirectory="c:\path\to\directory\you\can\write" /> 
+1

Wir hosten die Website über HostMySite und sie sagen mir weiterhin, dass sie keinen Schreibzugriff auf dieses Verzeichnis erlauben. Ich streite seit Tagen mit ihnen über dieses Thema. Empfehlen Sie, dass ich versuche, eine MSFT-Dokumentation zu finden, die Ihre obigen Informationen eindeutig angibt, um zu beweisen, dass sie nicht korrekt konfiguriert sind? Ich habe nur Probleme mit diesem Host gehabt, seit sie vor 6-8 Monaten re-plattformiert haben. Natürlich funktioniert die Anwendung in unserer Entwicklungsumgebung. – Grasshopper

+0

Die Supportperson, mit der Sie sprechen, versteht das wahrscheinlich nicht. Dieser MSDN Artikel erklärt es. Wenn das, was sie sagen, wahr ist, wäre fast jeder Standort zerstört. Wenn sie ** Ihnen ein Verzeichnis geben, in das Sie schreiben können, können Sie das in der 'web.config' setzen [um dieses Verzeichnis zu verwenden] (http://msdn.microsoft.com/en-us/library/ system.web.configuration.compilationsection.tempdirectory.aspx). –

+0

[Hier ist] (http://msdn.microsoft.com/en-us/library/s10awwz0.aspx) eine bessere Verbindung zu der 'tempDirectory' Einstellung. Im Grunde werden Sie '' innerhalb Ihres '' Elements in 'web.config'. –

8

hinzufügen Identität des Anwendungspools mit der IIS_IUSRS-Gruppe des Servers.

+0

Brilliant! Ich hatte den temporären ASP.NET-Dateien für meinen apppool-Benutzer Vollzugriff hinzugefügt. Aber nachdem ich den apppool-Benutzer der IIS_IUSERS-Gruppe hinzugefügt hatte, konnte ich die Vollzugriff-Berechtigung entfernen und alles funktionierte perfekt. Danke vielmals! – rob

1

Ich hatte die Anwendungspoolidentität setzen NetworkService- und dann den Benutzer auf meiner Website (der Benutzer du verbinden als "in IIS-Einstellungen unter Basic Settings für Ihre Website) an die IIS_IUSRS Gruppe

0

auch Verbindungs ​​hinzufügen asp.net, finden die Schritte von unten neu installieren können:

cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ 
aspnet_iis -i 
1

ich hatte diesen Fehler, wenn ich den physischen Pfad Credentials festgelegt (in Erweiterte Einstellungen) auf meine Bewerbung Becken Konto.

In meinem Fall war der Fix zum Zurücksetzen der Physical Path Credentials zu "Application user" und zur Behebung meines ursprünglichen Fehlers mit this answer, dh zum Zurücksetzen der anonymen Authentifizierung auf Application Pool-Identität, die für diese bestimmte Website IUSR war, ein Benutzer die keinen Zugriff auf den Anwendungspfad hatten (da wir einen bestimmten Benutzer für die App-Pool-Identität verwenden).