ASP.NET wdrażanie w Internecie przy użyciu programu Visual Studio: rozwiązywanie problemów
Autor : Tom Dykstra
W tej serii samouczków pokazano, jak wdrożyć (opublikować) aplikację internetową ASP.NET w celu Azure App Service Web Apps lub dostawcy hostingu innej firmy przy użyciu programu Visual Studio 2012 lub Visual Studio 2010. Aby uzyskać informacje o serii, zobacz pierwszy samouczek z serii.
Na tej stronie opisano niektóre typowe problemy, które mogą wystąpić podczas wdrażania aplikacji internetowej ASP.NET przy użyciu programu Visual Studio. Dla każdego z nich podano co najmniej jedną możliwą przyczynę i odpowiednie rozwiązania.
Przedstawione scenariusze dotyczą zarówno platformy Azure, jak i dostawców hostingu innych firm. Aby uzyskać więcej informacji na temat rozwiązywania problemów z aplikacjami internetowymi w Azure App Service, zobacz następujące zasoby:
- Rozwiązywanie problemów z aplikacją internetową w Azure App Service przy użyciu programu Visual Studio
- Monitorowanie Web Apps w usłudze Azure App Service
- Ogłoszenie wydania zestawu Windows Azure SDK 2.0 dla platformy .NET (blog ScottGu przedstawia sposób pobierania dzienników diagnostycznych w programie Visual Studio)
Błąd serwera w aplikacji "/" — bieżące ustawienia błędu niestandardowego uniemożliwiają zdalne wyświetlanie szczegółów błędu
Scenariusz
Po wdrożeniu lokacji na hoście zdalnym zostanie wyświetlony komunikat o błędzie informujący o ustawieniu customErrors w pliku Web.config, ale nie wskazuje, jaka była rzeczywista przyczyna błędu:
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".
Możliwa przyczyna i rozwiązanie
Domyślnie ASP.NET wyświetla szczegółowe informacje o błędzie tylko wtedy, gdy aplikacja internetowa jest uruchomiona na komputerze lokalnym. Ogólnie rzecz biorąc, nie chcesz wyświetlać szczegółowych informacji o błędach, gdy aplikacja internetowa jest publicznie dostępna za pośrednictwem Internetu, ponieważ hakerzy mogą używać tych informacji do znajdowania luk w zabezpieczeniach w aplikacji. Jednak podczas wdrażania lokacji lub aktualizacji w lokacji czasami coś pójdzie nie tak i trzeba uzyskać rzeczywisty komunikat o błędzie.
Aby umożliwić aplikacji wyświetlanie szczegółowych komunikatów o błędach podczas uruchamiania na hoście zdalnym, zmodyfikuj plik Web.config, aby ustawić tryb customErrors, ponownie wdrożyć aplikację i ponownie uruchomić aplikację:
Jeśli plik Web.config aplikacji ma element customErrors w elemecie system.web, zmień atrybut mode na "off". W przeciwnym razie dodaj element customErrors w elemecie system.web z atrybutem mode ustawionym na wartość "off", jak pokazano w poniższym przykładzie:
<configuration> <system.web> <customErrors mode="off"/> </system.web> </configuration>Wdrażanie aplikacji.
Uruchom aplikację i powtórz to, co wcześniej spowodowało wystąpienie błędu. Teraz możesz zobaczyć, jaki jest rzeczywisty komunikat o błędzie.
Po usunięciu błędu przywróć oryginalne ustawienie customErrors i ponownie wdróż aplikację.
Nie można utworzyć/kopii w tle "ContosoUniversity", gdy ten plik już istnieje.
Scenariusz
Podczas próby uruchomienia projektu w programie Visual Studio zostanie wyświetlona strona błędu z komunikatem podobny do następującego przykładu:
Błąd serwera w aplikacji "/". Nie można utworzyć/kopii w tle "ContosoUniversity", gdy ten plik już istnieje.
Możliwa przyczyna i rozwiązanie
Poczekaj chwilę i odśwież przeglądarkę lub ponownie skompiluj witrynę i spróbuj uruchomić ją ponownie.
Odmowa dostępu na stronie sieci Web korzystającej z SQL Server Compact
Scenariusz
Podczas wdrażania lokacji korzystającej z SQL Server Compact i uruchomienia strony w wdrożonej lokacji, która uzyskuje dostęp do bazy danych, zostanie wyświetlony następujący komunikat o błędzie:
Odmowa dostępu. (Wyjątek od HRESULT: 0x80070005 (E_ACCESSDENIED))
Możliwa przyczyna i rozwiązanie
Konto USŁUGI SIECIOWEJ na serwerze musi mieć możliwość odczytu plików binarnych natywnych SQL Service Compact, które znajdują się w folderze bin\amd64 lub bin\x86 , ale nie ma uprawnień do odczytu dla tych folderów. Ustaw uprawnienie do odczytu dla usługi SIECIOWEJ w folderze bin , upewniając się, że uprawnienia są rozszerzane do podfolderów.
Nie można odczytać pliku konfiguracji z powodu niewystarczających uprawnień
Scenariusz
Po kliknięciu przycisku Publikowania programu Visual Studio w celu wdrożenia aplikacji w usługach IIS na komputerze lokalnym publikowanie kończy się niepowodzeniem, a w oknie Dane wyjściowe zostanie wyświetlony komunikat o błędzie podobny do następującego:
Wystąpił błąd podczas odczytywania pliku konfiguracji usług IIS "MACHINE/REDIRECTION". Tożsamość wykonująca tę operację była ... Błąd: Nie można odczytać pliku konfiguracji z powodu niewystarczających uprawnień.
Możliwa przyczyna i rozwiązanie
Aby użyć jednokrotnego publikowania w usługach IIS na komputerze lokalnym, musisz uruchomić program Visual Studio z uprawnieniami administratora. Zamknij program Visual Studio i uruchom go ponownie z uprawnieniami administratora.
Nie można nawiązać połączenia z komputerem docelowym ... Korzystanie z określonego procesu
Scenariusz
Po kliknięciu przycisku Publikowania programu Visual Studio w celu wdrożenia aplikacji publikowanie zakończy się niepowodzeniem, a w oknie Dane wyjściowe zostanie wyświetlony komunikat o błędzie podobny do następującego:
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.
Możliwa przyczyna i rozwiązanie
Serwer proxy przerywa komunikację z serwerem docelowym. W Panel sterowania Windows lub w programie Internet Explorer wybierz pozycję Opcje internetowe i wybierz kartę Połączenia. W oknie dialogowym Właściwości internetowe kliknij pozycję Ustawienia sieci LAN. W oknie dialogowym Ustawienia sieci lokalnej (LAN) wyczyść pole wyboru Automatycznie wykrywaj ustawienia . Następnie ponownie kliknij przycisk Publikuj.
Jeśli problem będzie się powtarzać, skontaktuj się z administratorem systemu, aby określić, co można zrobić za pomocą ustawień serwera proxy lub zapory. Problem występuje, ponieważ narzędzie Web Deploy używa standardowego portu do wdrożenia usługi zarządzania siecią Web (8172); w przypadku innych połączeń narzędzie Web Deploy używa portu 80. Podczas wdrażania u innego dostawcy hostingu zazwyczaj używasz usługi zarządzania siecią Web.
Domyślna pula aplikacji .NET 4.0 nie istnieje
Scenariusz
Podczas wdrażania aplikacji wymagającej .NET Framework 4 zostanie wyświetlony następujący komunikat o błędzie:
Domyślna pula aplikacji .NET 4.0 nie istnieje lub nie można dodać aplikacji. Sprawdź, czy na tym komputerze zainstalowano ASP.NET 4.0.
Możliwa przyczyna i rozwiązanie
ASP.NET 4 nie jest zainstalowany w usługach IIS. Jeśli wdrażany serwer jest komputerem dewelopera i ma zainstalowany na nim program Visual Studio 2010, ASP.NET 4 jest zainstalowany na komputerze, ale może nie być zainstalowany w usługach IIS. Na serwerze, w którym wdrażasz, otwórz wiersz polecenia z podwyższonym poziomem uprawnień i zainstaluj ASP.NET 4 w usługach IIS, uruchamiając następujące polecenia:
cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru
Może być również konieczne ręczne ustawienie .NET Framework wersji domyślnej puli aplikacji. Aby uzyskać więcej informacji, zobacz samouczek Wdrażanie w usługach IIS jako środowisko testowe w tej serii.
Format ciągu inicjowania nie jest zgodny ze specyfikacją rozpoczynającą się od indeksu 0.
Scenariusz
Po wdrożeniu aplikacji przy użyciu publikowania jednym kliknięciem po uruchomieniu strony, która uzyskuje dostęp do bazy danych, zostanie wyświetlony następujący komunikat o błędzie:
Format ciągu inicjowania nie jest zgodny ze specyfikacją rozpoczynającą się od indeksu 0.
Możliwa przyczyna i rozwiązanie
Otwórz plik Web.config w wdrożonej lokacji i sprawdź, czy wartości parametrów połączenia zaczynają się od $(ReplaceableToken_, jak w poniższym przykładzie:
<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>
Jeśli parametry połączenia wyglądają jak w tym przykładzie, zmodyfikuj plik projektu i dodaj następującą właściwość do elementu PropertyGroup, który jest przeznaczony dla wszystkich konfiguracji kompilacji:
<AutoParameterizationWebConfigConnectionStrings>False</AutoParameterizationWebConfigConnectionStrings>
Następnie ponownie wdróż aplikację.
Wewnętrzny błąd serwera HTTP 500
Scenariusz
Po uruchomieniu wdrożonej witryny zostanie wyświetlony następujący komunikat o błędzie bez określonych informacji wskazujących przyczynę błędu:
Błąd HTTP 500 — wewnętrzny błąd serwera.
Możliwa przyczyna i rozwiązanie
Istnieje wiele przyczyn błędów 500, ale jedną z możliwych przyczyn w przypadku korzystania z tych samouczków jest umieszczenie elementu XML w niewłaściwym miejscu w jednym z plików transformacji Web.config. Na przykład ten błąd występuje, jeśli umieścisz przekształcenie, które wstawia <element lokalizacji> w pliku <system.web> zamiast bezpośrednio w <konfiguracji>. Możesz użyć funkcji przekształcania Web.config w wersji zapoznawczej, aby sprawdzić, czy przekształcenia działają zgodnie z oczekiwaniami. Rozwiązaniem, jeśli znajdziesz przekształcenie, które zostało zakodowane niepoprawnie, jest poprawienie pliku transformacji i ponowne wdrożenie. Jeśli błąd nie jest oczywisty, spróbuj skomentować przekształcenia i ponownie wdrożyć, aby zobaczyć, który z nich powoduje błąd 500.
Wewnętrzny błąd serwera HTTP 500.21
Scenariusz
Po uruchomieniu wdrożonej witryny zostanie wyświetlony następujący komunikat o błędzie:
Błąd HTTP 500.21 — wewnętrzny błąd serwera. Program obsługi "PageHandlerFactory-Integrated" ma zły moduł "ManagedPipelineHandler" na liście modułów.
Możliwa przyczyna i rozwiązanie
Wdrożona witryna docelowa ASP.NET 4, ale ASP.NET 4 nie jest zarejestrowana w usługach IIS na serwerze. Na serwerze otwórz wiersz polecenia z podwyższonym poziomem uprawnień i zarejestruj ASP.NET 4, uruchamiając następujące polecenia:
cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru
Może być również konieczne ręczne ustawienie .NET Framework wersji domyślnej puli aplikacji. Aby uzyskać więcej informacji, zobacz samouczek Wdrażanie w usługach IIS jako środowisko testowe w tej serii.
Logowanie nie powiodło się podczas otwierania bazy danych SQL Server Express w App_Data
Scenariusz
Zaktualizowano parametry połączenia pliku Web.config, aby wskazywały bazę danych SQL Server Express jako plik mdf w folderze App_Data, a po raz pierwszy uruchomisz aplikację, zostanie wyświetlony następujący komunikat o błędzie:
System.Data.SqlClient.SqlException: Nie można otworzyć bazy danych "DatabaseName" żądanej przez identyfikator logowania. Logowanie nie powiodło się.
Możliwa przyczyna i rozwiązanie
Nazwa pliku mdf nie może być zgodna z nazwą żadnej bazy danych SQL Server Express, która kiedykolwiek istniała na komputerze, nawet jeśli plik mdf wcześniej istniejącej bazy danych został usunięty. Zmień nazwę pliku mdf na nazwę, która nigdy nie została użyta jako nazwa bazy danych, a następnie zmień plik Web.config , aby użyć nowej nazwy. Alternatywnie możesz użyć SQL Server Management Studio Express do usunięcia wcześniej istniejących baz danych SQL Server Express.
Nie można sprawdzić zgodności modelu
Scenariusz
Zaktualizowano parametry połączenia pliku Web.config, aby wskazywały nową bazę danych SQL Server Express i po raz pierwszy uruchomisz aplikację, zostanie wyświetlony następujący komunikat o błędzie:
Nie można sprawdzić zgodności modelu, ponieważ baza danych nie zawiera metadanych modelu. Upewnij się, że element IncludeMetadataConvention został dodany do konwencji DbModelBuilder.
Możliwa przyczyna i rozwiązanie
Jeśli nazwa bazy danych umieszczona w pliku Web.config była kiedykolwiek używana wcześniej na komputerze, baza danych może już istnieć z niektórymi tabelami w nim. Wybierz nową nazwę, która nie została użyta na komputerze przed i zmień plik Web.config , aby wskazać, aby użyć tej nowej nazwy bazy danych. Alternatywnie możesz użyć narzędzia SQL Server Express lub SQL Server Management Studio Express, aby usunąć istniejącą bazę danych.
Błąd SQL, gdy skrypt próbuje utworzyć użytkowników lub role
Scenariusz
Używasz wdrożenia bazy danych skonfigurowanego na karcie Package/Publish SQL (Tworzenie użytkownika lub Tworzenie roli), a wykonywanie skryptu kończy się niepowodzeniem po wykonaniu tych poleceń. Mogą pojawić się bardziej szczegółowe komunikaty, takie jak następujące:
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.
Jeśli ten błąd występuje podczas konfigurowania wdrożenia bazy danych w kreatorze publikowania sieci Web , a nie na karcie Package/Publish SQL( Pakiet/Publikowanie bazy danych SQL ), utwórz wątek na forum Konfiguracja i wdrożenie , a rozwiązanie zostanie dodane do tej strony rozwiązywania problemów.
Możliwa przyczyna i rozwiązanie
Konto użytkownika używane do wykonania wdrożenia nie ma uprawnień do tworzenia użytkowników ani ról. Na przykład firma hostingowa może przypisać db_datareader, db_datawriter i db_ddladmin role do konta użytkownika, które konfiguruje. Są one wystarczające do tworzenia większości obiektów bazy danych, ale nie do tworzenia użytkowników lub ról. Jednym ze sposobów uniknięcia błędu jest wykluczenie użytkowników i ról z wdrożenia bazy danych. Można to zrobić, edytując element PreSource dla automatycznie wygenerowanego skryptu bazy danych, aby zawierał następujące atrybuty:
CopyAllUsers=false, CopyAllRoles=false
Aby uzyskać informacje na temat edytowania elementu PreSource w pliku projektu, zobacz How to: Edit Deployment Settings in the Project File (Instrukcje: edytowanie ustawień wdrożenia w pliku projektu). Jeśli użytkownicy lub role w bazie danych deweloperskich muszą znajdować się w docelowej bazie danych, skontaktuj się z dostawcą hostingu, aby uzyskać pomoc.
SQL Server błąd przekroczenia limitu czasu podczas uruchamiania skryptów niestandardowych podczas wdrażania
Scenariusz
Określono niestandardowe skrypty SQL do uruchamiania podczas wdrażania, a gdy narzędzie Web Deploy je uruchamia, upłynął limit czasu.
Możliwa przyczyna i rozwiązanie
Uruchamianie wielu skryptów z różnymi trybami transakcji może powodować błędy przekroczenia limitu czasu. Domyślnie skrypty generowane automatycznie są uruchamiane w transakcji, ale skrypty niestandardowe nie. W przypadku wybrania opcji Ściąganie danych i/lub schematu z istniejącej bazy danych na karcie Package/Publish SQL (Pakiet/Publikowanie kodu SQL ), a jeśli dodasz niestandardowy skrypt SQL, musisz zmienić ustawienia transakcji na niektórych skryptach, aby wszystkie skrypty używały tych samych ustawień transakcji. Aby uzyskać więcej informacji, zobacz How to: Deploy a Database With a Web Application Project (Jak wdrożyć bazę danych za pomocą projektu aplikacji internetowej).
Jeśli skonfigurowano ustawienia transakcji tak, aby wszystkie te same, ale nadal występują te błędy, możliwe obejście polega na osobnym uruchomieniu skryptów. W siatce Skrypty bazy danych na karcie Package/Publish SQL usuń zaznaczenie pola wyboru Dołącz dla skryptu, który powoduje błąd przekroczenia limitu czasu, a następnie opublikuj projekt. Następnie wróć do siatki Skrypty bazy danych , zaznacz to pole wyboru Dołącz skrypt i wyczyść pola wyboru Dołącz dla innych skryptów. Następnie ponownie opublikuj projekt. Tym razem po opublikowaniu zostanie uruchomiony tylko wybrany skrypt niestandardowy.
Dane strumienia manifestu witryny nie są jeszcze dostępne
Scenariusz
Podczas instalowania pakietu przy użyciu pliku deploy.cmd z opcją t (test) zostanie wyświetlony następujący komunikat o błędzie:
Błąd: dane strumienia "sitemanifest/dbFullSql[@path='C:\TEMP\AdventureWorksGrant.sql']/sqlScript" nie są jeszcze dostępne.
Możliwa przyczyna i rozwiązanie
Komunikat o błędzie oznacza, że polecenie nie może utworzyć raportu testowego. Jednak polecenie może zostać uruchomione, jeśli używasz opcji y (rzeczywista instalacja). Komunikat wskazuje tylko, że występuje problem z uruchomieniem polecenia w trybie testowym.
Ta aplikacja wymaga elementu ManagedRuntimeVersion w wersji 4.0
Scenariusz
Podczas próby wdrożenia zostanie wyświetlony następujący komunikat o błędzie:
Pula aplikacji, której próbujesz użyć, ma właściwość "managedRuntimeVersion" ustawioną na "v2.0". Ta aplikacja wymaga wersji 4.0.
Możliwa przyczyna i rozwiązanie
ASP.NET 4 nie jest zainstalowany w usługach IIS. Jeśli wdrażany serwer jest komputerem dewelopera i ma zainstalowany program Visual Studio 2010, ASP.NET 4 jest zainstalowany na komputerze, ale może nie być zainstalowany w usługach IIS. Na serwerze wdrażanym w programie otwórz wiersz polecenia z podwyższonym poziomem uprawnień i zainstaluj ASP.NET 4 w usługach IIS, uruchamiając następujące polecenia:
cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –i
Nie można oddać elementu Microsoft.Web.Deployment.DeploymentProviderOptions
Scenariusz
Podczas wdrażania pakietu zostanie wyświetlony następujący komunikat o błędzie:
Nie można rzutować obiektu typu "Microsoft.Web.Deployment.DeploymentProviderOptions" na wartość "Microsoft.Web.Deployment.DeploymentProviderOptions".
Możliwa przyczyna i rozwiązanie
Próbujesz wdrożyć z menedżera usług IIS przy użyciu interfejsu użytkownika web deploy 1.1 na serwerze z zainstalowanym programem Web Deploy 2.0. Jeśli używasz narzędzia administracji zdalnej usług IIS do wdrożenia przez zaimportowanie pakietu, zaznacz okno dialogowe Nowe dostępne funkcje podczas nawiązywania połączenia. (To okno dialogowe może być wyświetlane tylko raz, gdy połączenie zostanie nawiązane po raz pierwszy. Aby wyczyścić połączenie i rozpocząć pracę, zamknij Menedżera usług IIS i uruchom go ponownie, wprowadzając polecenie inetmgr /reset w wierszu polecenia). Jeśli jedną z wymienionych funkcji jest interfejs użytkownika web deploy i ma numer wersji mniejszy niż 8, wdrażany serwer może mieć zainstalowane wersje 1.1 i 2.0 narzędzia Web Deploy. Aby wdrożyć z poziomu klienta z zainstalowanym programem 2.0, serwer musi mieć zainstalowany tylko program Web Deploy 2.0. Aby rozwiązać ten problem, musisz skontaktować się z dostawcą hostingu.
Nie można załadować składników natywnych SQL Server Compact
Scenariusz
Po uruchomieniu wdrożonej lokacji zostanie wyświetlony następujący komunikat o błędzie:
Nie można załadować natywnych składników SQL Server Compact odpowiadających dostawcy ADO.NET wersji 8482. Zainstaluj poprawną wersję SQL Server Compact. Aby uzyskać więcej informacji, zapoznaj się z artykułem kb 974247.
Możliwa przyczyna i rozwiązanie
Wdrożona lokacja nie ma podfolderów amd64 i x86 z zestawami natywnymi w nich w folderze bin aplikacji. Na komputerze, na którym zainstalowano SQL Server Compact, zestawy natywne znajdują się w folderze C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private. Najlepszym sposobem uzyskania poprawnych plików do odpowiednich folderów w projekcie programu Visual Studio jest zainstalowanie pakietu NuGet SqlServerCompact. Instalacja pakietu dodaje skrypt po kompilacji, aby skopiować zestawy natywne do procesorów amd64 i x86. Aby można było je wdrożyć, należy jednak ręcznie uwzględnić je w projekcie. Aby uzyskać więcej informacji, zobacz samouczek Wdrażanie SQL Server Compact.
Błąd "Ścieżka jest nieprawidłowa" po wdrożeniu aplikacji Entity Framework Code First
Scenariusz
Wdrażasz aplikację, która używa migracje Code First platformy Entity Framework i systemu DBMS, takiego jak SQL Server Compact, która przechowuje swoją bazę danych w pliku w folderze App_Data. Po pierwszym wdrożeniu skonfigurowano Migracje Code First utworzyć bazę danych. Po uruchomieniu aplikacji zostanie wyświetlony komunikat o błędzie podobny do następującego przykładu:
Ścieżka jest nieprawidłowa. Sprawdź katalog bazy danych. [Path = c:\inetpub\wwwroot\App_Data\DatabaseName.sdf ]
Możliwa przyczyna i rozwiązanie
Code First próbuje utworzyć bazę danych, ale folder App_Data nie istnieje. Podczas wdrażania nie masz żadnych plików w folderze App_Data lub wybrano opcję Wyklucz App_Data na karcie Pakiet/Publikowanie w sieci Web w okno Właściwości projektu. Proces wdrażania nie utworzy folderu na serwerze, jeśli nie ma plików w folderze do skopiowania na serwer. Jeśli baza danych została już skonfigurowana w lokacji, proces wdrażania spowoduje usunięcie plików i samego folderu App_Data po wybraniu opcji Usuń dodatkowe pliki w miejscu docelowym w profilu publikowania. Aby rozwiązać ten problem, umieść plik zastępczy, taki jak plik .txt w folderze App_Data , upewnij się, że nie wybrano opcji Wyklucz App_Data i ponownie wdróż.
"Nie można użyć obiektu COM, który został oddzielony od bazowej wersji RCW".
Scenariusz
Pomyślnie wdrożono aplikację przy użyciu jednego kliknięcia publikowania, a następnie zaczniesz otrzymywać następujący błąd:
Zadanie wdrażania sieci Web nie powiodło się. (Nie można ukończyć żądania do adresu URL agenta zdalnego '<https://serverurl.com/msdeploy.axd?site=sitename>').
Nie można ukończyć żądania do adresu URL agenta zdalnego "<https://url/msdeploy.axd?site=sitename>".
Żądanie zostało przerwane: żądanie zostało anulowane.
Nie można użyć obiektu COM oddzielonego od bazowej wersji RCW.
Możliwa przyczyna i rozwiązanie
Zamknięcie i ponowne uruchomienie programu Visual Studio jest zwykle wymagane do rozwiązania tego błędu.
Wdrażanie kończy się niepowodzeniem, ponieważ poświadczenia użytkownika używane do publikowania nie mają ustawionego urzędu kontroli dostępu
Scenariusz
Publikowanie kończy się niepowodzeniem z powodu błędu wskazującego, że nie masz uprawnień do ustawiania uprawnień folderu (używane konto użytkownika nie ma urzędu setACL).
Możliwa przyczyna i rozwiązanie
Domyślnie program Visual Studio ustawia uprawnienia do odczytu w folderze głównym witryny i uprawnienia do zapisu w folderze App_Data. Jeśli wiesz, że domyślne uprawnienia w folderach lokacji są poprawne i nie trzeba ich ustawiać, należy wyłączyć to zachowanie, dodając <parametr IncludeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> do pliku profilu publikowania (aby mieć wpływ na jeden profil) lub do pliku wpp.targets (aby mieć wpływ na wszystkie profile). Aby uzyskać informacje o sposobie edytowania tych plików, zobacz How to: Edit Deployment Settings in Profile (.pubxml) Files (Instrukcje: Edytowanie ustawień wdrożenia w plikach profilu (.pubxml).
Błędy odmowy dostępu, gdy aplikacja próbuje zapisać w folderze aplikacji
Scenariusz
Błędy aplikacji podczas próby utworzenia lub edytowania pliku w jednym z folderów aplikacji, ponieważ nie ma urzędu zapisu dla tego folderu.
Możliwa przyczyna i rozwiązanie
Domyślnie program Visual Studio ustawia uprawnienia do odczytu w folderze głównym witryny i uprawnienia do zapisu w folderze App_Data. Jeśli aplikacja potrzebuje dostępu do zapisu do podfolderu, możesz ustawić uprawnienia dla tego folderu, jak pokazano w samouczkach Ustawianie uprawnień folderów i Wdrażanie w środowisku produkcyjnym w tej serii. Jeśli aplikacja potrzebuje dostępu do zapisu w folderze głównym witryny, musisz uniemożliwić jej ustawienie dostępu tylko do odczytu w folderze głównym przez dodanie <właściwości IncludeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> do pliku profilu publikowania (aby wpłynąć na jeden profil) lub do pliku wpp.targets (aby mieć wpływ na wszystkie profile). Aby uzyskać informacje o sposobie edytowania tych plików, zobacz How to: Edit Deployment Settings in Profile (.pubxml) Files (Instrukcje: Edytowanie ustawień wdrożenia w plikach profilu (.pubxml).
Błąd konfiguracji — atrybut targetFramework odwołuje się do wersji nowszej niż zainstalowana wersja .NET Framework
Scenariusz
Pomyślnie opublikowano projekt internetowy przeznaczony dla ASP.NET 4.5, ale po uruchomieniu aplikacji (z trybem customErrors ustawionym na "wyłączone" w pliku Web.config) zostanie wyświetlony następujący błąd:
Atrybut "targetFramework" w <elemecie kompilacji> pliku Web.config jest używany tylko do docelowej wersji 4.0 i nowszej .NET Framework (na przykład "<kompilacja targetFramework="4.0".> Atrybut "targetFramework" obecnie odwołuje się do wersji nowszej niż zainstalowana wersja .NET Framework. Określ prawidłową wersję docelową .NET Framework lub zainstaluj wymaganą wersję .NET Framework.
W polu Błąd źródłowy strony błędu wyróżniono następujący wiersz z Web.config jako przyczynę błędu:
<kompilacja targetFramework="4.5" />
Możliwa przyczyna i rozwiązanie
Serwer nie obsługuje ASP.NET 4.5. Skontaktuj się z dostawcą hostingu, aby określić, kiedy i czy można dodać obsługę ASP.NET 4.5. Jeśli uaktualnienie serwera nie jest opcją, musisz wdrożyć projekt internetowy przeznaczony dla ASP.NET 4 lub starszej wersji.
Jeśli wdrożysz projekt ASP.NET 4 lub starszy projekt internetowy w tym samym miejscu docelowym, zaznacz pole wyboru Usuń dodatkowe pliki w miejscu docelowym na karcie Ustawienia kreatora Publikowanie w sieci Web . Jeśli nie wybierzesz opcji Usuń dodatkowe pliki w miejscu docelowym, będziesz nadal otrzymywać stronę Błąd konfiguracji.
Okna właściwości projektu zawierają listę rozwijaną Struktura docelowa, ale nie można rozwiązać tego problemu, zmieniając tę wartość z .NET Framework 4.5 na .NET Framework 4. Jeśli zmienisz strukturę docelową na starszą wersję platformy, projekt nadal będzie miał odwołania do zestawów nowszej wersji platformy i nie zostanie uruchomiony. Musisz ręcznie zmienić te odwołania lub utworzyć nowy projekt przeznaczony dla .NET Framework 4 lub starszej wersji. Aby uzyskać więcej informacji, zobacz .NET Framework Target for Web Sites (Określanie wartości docelowej dla witryn sieci Web).
Błędy średniej zaufania
Scenariusz
Po uruchomieniu aplikacji w środowisku produkcyjnym występuje błąd związany z średnim zaufaniem.
Możliwa przyczyna i rozwiązanie
Wielu dostawców hostingu innych firm uruchamia witrynę internetową w średnim zaufaniu, co oznacza, że istnieje kilka rzeczy, których nie można zrobić. Na przykład kod aplikacji nie może uzyskać dostępu do rejestru systemu Windows i nie może odczytywać ani zapisywać plików spoza hierarchii folderów aplikacji. Domyślnie aplikacja działa w pełnym zaufaniu na komputerze lokalnym, co oznacza, że aplikacja może wykonywać czynności, które mogłyby zakończyć się niepowodzeniem podczas wdrażania jej w środowisku produkcyjnym.
Aplikację można skonfigurować do uruchamiania w średnim zaufaniu w lokalnym środowisku usług IIS w celu rozwiązania problemów. W tym celu otwórz plik Web.config aplikacji i dodaj element trust w elemecie system.web , jak pokazano w tym przykładzie.
<configuration>
<!-- Settings -->
<system.web>
<trust level="Medium" />
<!-- Settings -->
</system.web>
</configuration>
Aplikacja będzie teraz działać w średnim zaufaniu w usługach IIS nawet na komputerze lokalnym.
Nie należy tego robić, jeśli wdrażasz w Azure App Service, ponieważ platforma Azure nie wymaga średniej relacji zaufania. W momencie pisania tego samouczka w lutym 2012 r. użycie tej metody w celu uruchomienia aplikacji w średnim zaufaniu spowoduje błąd na platformie Azure.
Jeśli używasz migracje Code First platformy Entity Framework i wdrażasz go u dostawcy hostingu, który uruchamia aplikację w średnim zaufaniu, upewnij się, że masz zainstalowaną wersję 5.0 lub nowszą. W programie Entity Framework w wersji 4.3 migracje wymagają pełnego zaufania w celu zaktualizowania schematu bazy danych.
Błąd HTTP 404.17
Scenariusz
Po uruchomieniu wdrożonej witryny na komputerze dewelopera w usługach IIS zostanie wyświetlony następujący komunikat o błędzie informujący, że serwer nie może przetworzyć pliku Default.aspx:
Błąd HTTP 404.17 — nie znaleziono
Żądana zawartość wydaje się być skryptem i nie będzie obsługiwana przez program obsługi plików statycznych.
Możliwa przyczyna i rozwiązanie
ASP.NET 4.5 może nie być zainstalowany na komputerze. Zobacz kroki opisane w samouczku Wdrażanie w usługach IIS jako środowisko testowe w tej serii, aby wyjaśnić, jak zainstalować ASP.NET 4.5.