Zmiany powodujące niezgodność w platformie ASP.NET 4
W tym dokumencie opisano zmiany wprowadzone w wersji .NET Framework 4, które mogą potencjalnie mieć wpływ na aplikacje utworzone przy użyciu wcześniejszych wersji, w tym wersje ASP.NET 4 Beta 1 i Beta 2.
Zawartość
Ustawienie ControlRenderingCompatibilityVersion w pliku Web.config
Zmiany clientIDMode
Kodowanie htmlEncode i urlEncode teraz kodowanie pojedynczych cudzysłowów
analizator strony ASP.NET (aspx) jest bardziej rygorystyczny
Zaktualizowane pliki definicji przeglądarki
usunięte z głównego pliku konfiguracji sieci Web
ASP.NET
Domyślny algorytm tworzenia skrótów to teraz HMACSHA256
Błędy konfiguracji związane z nową konfiguracją katalogu głównego ASP.NET 4
można uruchomić aplikacji podrzędnych _Toc256770150 ASP.NET 4 w wersji ASP.NET 2.0 lub ASP.NET 3.5
nie można uruchomić 4 witryn sieci Web na komputerach z zainstalowanym programem SharePoint
Właściwość HttpRequest.FilePath nie zawiera już wartości PathInfo
ASP.NET 2.0 mogą generować błędy HttpException odwołujące się do pliku eurl.axd
Programy obsługi zdarzeń mogą nie być wywoływane w dokumencie domyślnym w trybie zintegrowanym usług IIS 7 lub IIS 7.5
Zmiany w implementacji zabezpieczeń dostępu kodu (CAS) ASP.NET
MembershipUser i inne typy w przestrzeni nazw System.Web.Security zostały przeniesione
Zmiany buforowania danych wyjściowych w różnych * nagłówek HTTP
Typy System.Web.Security dla usługi Passport są przestarzałe
Właściwość MenuItem.PopOutImageUrl nie może renderować obrazu w ASP.NET 4
Menu.StaticPopOutImageUrl i Menu.DynamicPopOutImageUrl nie mogą renderować obrazów, gdy ścieżki zawierają ukośniki odwrotne
Zastrzeżenie
Ustawienie ControlRenderingCompatibilityVersion w pliku Web.config
ASP.NET kontrolki zostały zmodyfikowane w .NET Framework w wersji 4, aby umożliwić dokładniejsze określenie sposobu renderowania znaczników. W poprzednich wersjach .NET Framework niektóre kontrolki emitowały znaczniki, których nie można było wyłączyć. Domyślnie ASP.NET 4 tego typu znaczników nie jest już generowany.
Jeśli używasz programu Visual Studio 2010 do uaktualniania aplikacji z wersji ASP.NET 2.0 lub ASP.NET 3.5, narzędzie automatycznie dodaje ustawienie do Web.config pliku, który zachowuje starsze renderowanie. Jeśli jednak uaktualnisz aplikację, zmieniając pulę aplikacji w usługach IIS na docelową .NET Framework 4, ASP.NET domyślnie używa nowego trybu renderowania. Aby wyłączyć nowy tryb renderowania, dodaj następujące ustawienie w Web.config pliku :
<pages controlRenderingCompatibilityVersion="3.5" />
Główne zmiany renderowania wprowadzone przez nowe zachowanie są następujące:
- Kontrolki Image i ImageButton nie renderuje już atrybutu
border="0". - Kontrolki klasy BaseValidator i sprawdzania poprawności, które pochodzą z niej, nie renderuje już domyślnie czerwonego tekstu.
- Kontrolka HtmlForm nie renderuje atrybutu name .
- Kontrolka Tabela nie renderuje już atrybutu
border="0". - Kontrolki, które nie są przeznaczone do wprowadzania danych przez użytkownika (na przykład kontrolki Etykieta ), nie renderują już atrybutu
disabled="disabled", jeśli właściwość Enabled jest ustawiona na wartość false (lub jeśli dziedziczą to ustawienie z kontrolki kontenera).
Zmiany clientIDMode
Ustawienie ClientIDMode w ASP.NET 4 umożliwia określenie, jak ASP.NET generuje atrybut id dla elementów HTML. W poprzednich wersjach ASP.NET domyślne zachowanie było równoważne ustawieniu AutoIDtrybu ClientIDMode. Jednak ustawienie domyślne jest teraz przewidywalne.
Jeśli używasz programu Visual Studio 2010 do uaktualniania aplikacji z wersji ASP.NET 2.0 lub ASP.NET 3.5, narzędzie automatycznie dodaje ustawienie do Web.config pliku, który zachowuje zachowanie wcześniejszych wersji .NET Framework. Jeśli jednak uaktualnisz aplikację, zmieniając pulę aplikacji w usługach IIS na docelową .NET Framework 4, ASP.NET domyślnie używa nowego trybu. Aby wyłączyć nowy tryb identyfikatora klienta, dodaj następujące ustawienie w Web.config pliku :
<pages clientIDMode="AutoID" />
Kodowanie htmlEncode i urlEncode teraz kodowanie pojedynczych cudzysłowów
W ASP.NET 4 metody HtmlEncode i UrlEncode klas HttpUtility i HttpServerUtility zostały zaktualizowane w celu zakodowania pojedynczego znaku cudzysłowu (') w następujący sposób:
- Metoda HtmlEncode koduje wystąpienia pojedynczego cudzysłowu jako .
- Metoda UrlEncode koduje wystąpienia pojedynczego cudzysłowu jako %27.
analizator strony ASP.NET (aspx) jest bardziej rygorystyczny
Analizator stron dla ASP.NET stron (.aspx plików) i kontrolek użytkownika (.ascx plików) jest bardziej rygorystyczny w ASP.NET 4 i odrzuci więcej wystąpień nieprawidłowych znaczników. Na przykład następujące dwa fragmenty kodu zostałyby pomyślnie przeanalizowane we wcześniejszych wersjach ASP.NET, ale teraz będą zgłaszać błędy analizatora w ASP.NET 4.
<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue" ; />
Zwróć uwagę na nieprawidłowy średnik na końcu tagu HiddenField .
<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
style="display:inline; CssClass="searchLink" />
Zwróć uwagę na nieujawniony atrybut stylu , który jest uruchamiany w atrybucie CssClass .
Zaktualizowane pliki definicji przeglądarki
Pliki definicji przeglądarki zostały zaktualizowane w celu uwzględnienia informacji o nowych i zaktualizowanych przeglądarkach i urządzeniach. Starsze przeglądarki i urządzenia, takie jak Netscape Navigator, zostały usunięte, a dodano nowsze przeglądarki i urządzenia, takie jak Google Chrome i Apple iPhone.
Jeśli aplikacja zawiera niestandardowe definicje przeglądarki dziedziczone z jednej z usuniętych definicji przeglądarki, zostanie wyświetlony błąd. Jeśli na przykład App_Browsers folder zawiera definicję przeglądarki dziedziczą po definicji przeglądarki IE2, zostanie wyświetlony następujący komunikat o błędzie konfiguracji:
- Nie można odnaleźć przeglądarki lub elementu bramy o identyfikatorze "IE2".
Uwaga
Obiekt HttpBrowserCapabilities (uwidoczniony przez właściwość Request.Browser strony) jest oparty na plikach definicji przeglądarki. W związku z tym informacje zwrócone przez uzyskanie dostępu do właściwości tego obiektu w ASP.NET 4 mogą różnić się od informacji zwróconych we wcześniejszej wersji ASP.NET.
Możesz przywrócić stare pliki definicji przeglądarki, kopiując pliki definicji przeglądarki z następującego folderu:
Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers
Skopiuj pliki do odpowiedniego \CONFIG\Browsers folderu dla ASP.NET 4. Po skopiowaniu plików uruchom narzędzie wiersza polecenia Aspnet_regbrowsers.exe.
System.Web.Mobile.dll usunięto z głównego pliku konfiguracji sieci Web
W poprzednich wersjach ASP.NET odwołanie do zestawu System.Web.Mobile.dll zostało uwzględnione w pliku głównym Web.config w sekcji zestawów poniżej. Aby zwiększyć wydajność, odwołanie do tego zestawu zostało usunięte.
Zestaw System.Web.Mobile.dll jest uwzględniony w ASP.NET 4, ale jest przestarzały. Jeśli chcesz użyć typów z zestawu System.Web.Mobile.dll, dodaj odwołanie do tego zestawu do pliku głównego Web.config lub do pliku aplikacji Web.config . Jeśli na przykład chcesz użyć dowolnego z (przestarzałych) kontrolek ASP.NET dla urządzeń przenośnych, musisz dodać odwołanie do zestawu System.Web.Mobile.dll do Web.config pliku.
weryfikacja żądania ASP.NET
Funkcja weryfikacji żądań w ASP.NET zapewnia pewien poziom domyślnej ochrony przed atakami skryptów między witrynami (XSS). W poprzednich wersjach ASP.NET walidacja żądania została domyślnie włączona. Jednak zastosowano ją tylko do ASP.NET stron (.aspx plików i ich plików klasy) i tylko wtedy, gdy te strony były wykonywane.
W ASP.NET 4 domyślnie walidacja żądania jest włączona dla wszystkich żądań, ponieważ jest włączona przed fazą BeginRequest żądania HTTP. W związku z tym walidacja żądania dotyczy żądań dla wszystkich zasobów ASP.NET, a nie tylko żądań stron aspx. Obejmuje to żądania, takie jak wywołania usługi sieci Web i niestandardowe procedury obsługi HTTP. Walidacja żądania jest również aktywna, gdy niestandardowe moduły HTTP odczytują zawartość żądania HTTP.
W związku z tym błędy weryfikacji żądania mogą teraz występować w przypadku żądań, które wcześniej nie wyzwoliły błędów. Aby przywrócić zachowanie funkcji weryfikacji żądania ASP.NET 2.0, dodaj następujące ustawienie w Web.config pliku:
<httpRuntime requestValidationMode="2.0" />
Zalecamy jednak analizowanie błędów weryfikacji żądań w celu określenia, czy istniejące programy obsługi, moduły lub inne niestandardowe kody uzyskują dostęp do potencjalnie niebezpiecznych danych wejściowych HTTP, które mogą być wektorami ataków XSS.
Domyślny algorytm tworzenia skrótów to teraz HMACSHA256
ASP.NET używa zarówno algorytmów szyfrowania, jak i tworzenia skrótów w celu zabezpieczenia danych, takich jak pliki cookie uwierzytelniania formularzy i stan wyświetlania. Domyślnie ASP.NET 4 używa teraz algorytmu HMACSHA256 na potrzeby operacji skrótu na plikach cookie i stanu wyświetlania. Starsze wersje ASP.NET używały starszego algorytmu HMACSHA1.
Aplikacje mogą mieć wpływ, jeśli uruchamiasz mieszane środowiska ASP.NET 2.0/ASP.NET 4, w których dane, takie jak pliki cookie uwierzytelniania formularzy, muszą działać across.NET wersje programu Framework. Aby skonfigurować aplikację internetową ASP.NET 4 do używania starszego algorytmu Web.config HMACSHA1, dodaj następujące ustawienie w pliku :
<machineKey validation="SHA1" />
Błędy konfiguracji związane z nową konfiguracją katalogu głównego ASP.NET 4
Pliki konfiguracji głównej (machine.configplik i plik głównyWeb.config) dla .NET Framework 4 (i w związku z tym ASP.NET 4) zostały zaktualizowane w celu uwzględnienia większości standardowych informacji o konfiguracji, które w ASP.NET 3.5 znaleziono w plikach aplikacjiWeb.config. Ze względu na złożoność zarządzanych systemów konfiguracji usług IIS 7 i IIS 7.5 uruchamianie aplikacji ASP.NET 3.5 w ASP.NET 4 oraz w usługach IIS 7 i IIS 7.5 może spowodować błędy konfiguracji ASP.NET lub IIS.
Zalecamy uaktualnienie aplikacji ASP.NET 3.5 do ASP.NET 4 przy użyciu narzędzi uaktualniania projektu w programie Visual Studio 2010, jeśli jest to praktyczne. Program Visual Studio 2010 automatycznie modyfikuje plik aplikacji Web.config ASP.NET 3.5, tak aby zawierał odpowiednie ustawienia dla ASP.NET 4.
Jest to jednak obsługiwany scenariusz uruchamiania aplikacji ASP.NET 3.5 przy użyciu .NET Framework 4 bez ponownej kompilacji. W takim przypadku może być konieczne ręczne zmodyfikowanie pliku aplikacji przed uruchomieniem aplikacji Web.config w .NET Framework 4 i w obszarze IIS 7 lub IIS 7.5.
W kolejnych dwóch sekcjach opisano zmiany, które mogą być konieczne w przypadku różnych kombinacji oprogramowania.
System Windows Vista z dodatkiem SP1 lub Windows Server 2008 z dodatkiem SP1, w którym nie zainstalowano ani poprawki KB958854, ani DODATKU SP2. W tej konfiguracji system konfiguracji usług IIS 7 niepoprawnie scala konfigurację zarządzaną przez aplikację, porównując plik na poziomie Web.config aplikacji z plikami ASP.NET 2.0 machine.config . W związku z tym pliki na poziomie Web.config aplikacji z .NET Framework 3.5 lub nowszym muszą mieć definicję sekcji konfiguracji system.web.extensions (element), aby nie powodować niepowodzenia weryfikacji usług IIS 7.
Jednak ręcznie zmodyfikowane wpisy plików na poziomie Web.config aplikacji, które nie są dokładnie zgodne z oryginalnymi definicjami sekcji konfiguracji standardowy, które zostały wprowadzone w programie Visual Studio 2008, spowodują błędy konfiguracji ASP.NET. (Domyślne wpisy konfiguracji generowane przez program Visual Studio 2008 działają poprawnie). Typowy problem polega na tym, że ręcznie zmodyfikowane Web.config pliki pomijają atrybuty konfiguracji allowDefinition i requirePermission , które znajdują się w różnych definicjach sekcji konfiguracji. Powoduje to niezgodność między skróconą sekcją konfiguracji w plikach na poziomie Web.config aplikacji a pełną definicją w pliku ASP.NET 4 machine.config . W związku z tym w czasie wykonywania system konfiguracji ASP.NET 4 zgłasza błąd konfiguracji.
Windows Vista z dodatkiem SP2, Windows Server 2008 z dodatkiem SP2, Windows 7, Windows Server 2008 R2, a także Windows Vista z dodatkiem SP1 i Windows Server 2008 z dodatkiem SP1, gdzie zainstalowano poprawkę KB958854.
W tym scenariuszu natywny system konfiguracji usług IIS 7 i IIS 7.5 zwraca błąd konfiguracji, ponieważ wykonuje porównanie tekstu atrybutu typu zdefiniowanego dla programu obsługi sekcji konfiguracji zarządzanej. Ponieważ wszystkie Web.config pliki generowane przez programy Visual Studio 2008 i Visual Studio 2008 z dodatkiem SP1 mają ciąg typu "3.5" dla procedur obsługi sekcji konfiguracji system.web.extensions (i powiązanych), i ponieważ plik ASP.NET 4 machine.config ma wartość "4.0" w atrybucie typu dla tych samych procedur obsługi sekcji konfiguracji, aplikacje generowane w programie Visual Studio 2008 lub Visual Studio 2008 z dodatkiem SP1 zawsze kończą się niepowodzeniem weryfikacji konfiguracji w usługach IIS 7 i IIS 7.5.
Rozwiązywanie tych problemów
Obejściem pierwszego scenariusza jest zaktualizowanie pliku na poziomie Web.config aplikacji przez dołączenie standardowego tekstu konfiguracji z pliku wygenerowanego Web.config automatycznie przez program Visual Studio 2008.
Alternatywnym obejściem pierwszego scenariusza jest zainstalowanie dodatku Service Pack 2 dla systemu Vista lub Windows Server 2008 na komputerze w celu naprawienia nieprawidłowego zachowania scalania konfiguracji systemu konfiguracji usług IIS. Jednak po wykonaniu jednej z tych akcji aplikacja prawdopodobnie napotka błąd konfiguracji z powodu problemu opisanego w drugim scenariuszu.
Obejściem drugiego scenariusza jest usunięcie lub oznaczanie komentarza wszystkich definicji sekcji konfiguracji system.web.extensions i definicji grup sekcji konfiguracji z pliku na poziomie Web.config aplikacji. Te definicje są zwykle na początku pliku na poziomie Web.config aplikacji i mogą być identyfikowane przez element configSections i jego elementy podrzędne.
W obu scenariuszach zaleca się również ręczne usunięcie sekcji system.codedom , chociaż nie jest to wymagane.
Nie można uruchomić aplikacji podrzędnych ASP.NET 4 w ASP.NET 2.0 lub ASP.NET 3.5
ASP.NET 4 aplikacje skonfigurowane jako elementy podrzędne aplikacji z wcześniejszymi wersjami ASP.NET mogą nie uruchomić się z powodu błędów konfiguracji lub kompilacji. Poniższy przykład przedstawia strukturę katalogów dla aplikacji, której dotyczy problem.
/parentwebapp (skonfigurowane do używania ASP.NET 2.0 lub ASP.NET 3.5)
/childwebapp (skonfigurowane do używania ASP.NET 4)
Uruchomienie aplikacji w folderze childwebapp nie powiedzie się w usługach IIS 7 lub IIS 7.5 i zgłosi błąd konfiguracji. Tekst błędu będzie zawierać komunikat podobny do następującego:
The requested page cannot be accessed because the related configuration data for the page is invalid.The configuration section 'configSections' cannot be read because it is missing a section declaration.
W usługach IIS 6 uruchomienie aplikacji w folderze childwebapp również zakończy się niepowodzeniem, ale zgłosi inny błąd. Na przykład tekst błędu może być następujący:
The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file
Te scenariusze występują, ponieważ informacje o konfiguracji z aplikacji nadrzędnej w parentwebapp folderze są częścią hierarchii informacji o konfiguracji, która określa końcowe scalone ustawienia konfiguracji, które są używane przez podrzędną aplikację internetową w folderze childwebapp . W zależności od tego, czy aplikacja internetowa ASP.NET 4 jest uruchomiona w usługach IIS 7 (lub IIS 7.5) lub IIS 6, system konfiguracji usług IIS lub system kompilacji ASP.NET 4 zwróci błąd.
Kroki, które należy wykonać, aby rozwiązać ten problem i uzyskać podrzędną aplikację ASP.NET 4 do pracy, zależą od tego, czy aplikacja ASP.NET 4 działa w usługach IIS 6 lub IIS 7 (lub IIS 7.5).
Krok 1 (tylko usługi IIS 7 lub IIS 7.5)
Ten krok jest niezbędny tylko w systemach operacyjnych z usługami IIS 7 lub IIS 7.5, w tym Windows Vista, Windows Server 2008, Windows 7 i Windows Server 2008 R2.
Przenieś definicję configSections w Web.config pliku aplikacji nadrzędnej (aplikacji z systemem ASP.NET 2.0 lub ASP.NET 3.5) do pliku głównego Web.config programu the.NET Framework 2.0. Natywny system konfiguracji usług IIS 7 i IIS 7.5 skanuje element configSections podczas scalania hierarchii plików konfiguracji. Przeniesienie definicji configSections z pliku nadrzędnej Web.config aplikacji sieci Web do pliku głównego Web.config skutecznie ukrywa element przed procesem scalania konfiguracji, który występuje dla aplikacji podrzędnej ASP.NET 4.
W 32-bitowym systemie operacyjnym lub w przypadku 32-bitowych pul Web.config aplikacji główny plik ASP.NET 2.0 i ASP.NET 3.5 zwykle znajduje się w następującym folderze:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG
W 64-bitowym systemie operacyjnym lub w przypadku 64-bitowych pul Web.config aplikacji główny plik ASP.NET 2.0 i ASP.NET 3.5 zwykle znajduje się w następującym folderze:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG
W przypadku uruchamiania zarówno 32-bitowych, jak i 64-bitowych aplikacji internetowych na komputerze 64-bitowym należy przenieść element configSections do plików głównych Web.config zarówno dla systemów 32-bitowych, jak i 64-bitowych.
Po wprowadzeniu elementu configSections w pliku głównym Web.config wklej sekcję bezpośrednio po elemecie konfiguracji . W poniższym przykładzie pokazano, jak powinna wyglądać górna część pliku głównego Web.config po zakończeniu przenoszenia elementów.
Uwaga
W poniższym przykładzie wiersze zostały opakowane pod kątem czytelności.
<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
<configSections>
<sectionGroup name="system.web.extensions"
type="System.Web.Configuration.SystemWebExtensionsSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<sectionGroup name="scripting"
type="System.Web.Configuration.ScriptingSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="scriptResourceHandler"
type="System.Web.Configuration.ScriptingScriptResourceHandlerSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<sectionGroup name="webServices"
type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="jsonSerialization"
type="System.Web.Configuration.ScriptingJsonSerializationSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="Everywhere" />
<section name="profileService"
type="System.Web.Configuration.ScriptingProfileServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="authenticationService"
type="System.Web.Configuration.ScriptingAuthenticationServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="roleService"
type="System.Web.Configuration.ScriptingRoleServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
</sectionGroup>
</sectionGroup>
</sectionGroup>
</configSections>
Krok 2 (wszystkie wersje usług IIS)
Ten krok jest wymagany, czy podrzędna aplikacja sieci Web ASP.NET 4 jest uruchomiona w usługach IIS 6, czy w usługach IIS 7 (lub IIS 7.5).
Web.config W pliku nadrzędnej aplikacji sieci Web z systemem ASP.NET 2 lub ASP.NET 3.5 dodaj tag lokalizacji, który jawnie określa (zarówno dla systemów konfiguracji usług IIS, jak i ASP.NET), że wpisy konfiguracji dotyczą tylko nadrzędnej aplikacji sieci Web. W poniższym przykładzie pokazano składnię elementu location do dodania:
<location path="" inheritInChildApplications="false" >
<!-- Additional settings -->
</location>
W poniższym przykładzie pokazano, jak tag lokalizacji jest używany do opakowania wszystkich sekcji konfiguracji, począwszy od sekcji appSettings i kończącej się sekcją system.webServer .
<location path="" inheritInChildApplications="false" >
<appSettings />
<connectionStrings />
<system.web>
<!-- Removed for brevity -->
</system.web>
<system.codedom>
<!-- Removed for brevity -->
</system.codedom>
<system.webServer>
<!-- Removed for brevity -->
</system.webServer>
</location>
Po wykonaniu kroków 1 i 2 podrzędne aplikacje internetowe ASP.NET 4 będą uruchamiane bez błędów.
nie można uruchomić ASP.NET 4 witryn sieci Web na komputerach, na których jest zainstalowany program SharePoint
Serwery sieci Web z uruchomionym programem SharePoint mają Web.config plik wdrożony w katalogu głównym witryny sieci Web programu SharePoint (na przykład c:\inetpub\wwwroot\web.config w przypadku domyślnej witryny sieci Web). W tym Web.config pliku program SharePoint ustawia niestandardowy poziom częściowo zaufania o nazwie WSS_Minimal.
Jeśli spróbujesz uruchomić witrynę sieci Web ASP.NET 4, która jest wdrożona jako element podrzędny tej witryny sieci Web programu SharePoint, zostanie wyświetlony następujący błąd:
Could not find permission set named 'ASP.NET'.
Ten błąd występuje, ponieważ infrastruktura zabezpieczeń dostępu kodu ASP.NET 4 (CAS) szuka zestawu uprawnień o nazwie ASP.NET. Jednak plik konfiguracji częściowego zaufania, do którego odwołuje się WSS_Minimal, nie zawiera żadnych zestawów uprawnień o tej nazwie.
Obecnie nie ma dostępnej wersji programu SharePoint zgodnej z ASP.NET. W związku z tym nie należy próbować uruchomić witryny sieci Web ASP.NET 4 jako witryny podrzędnej pod witrynami sieci Web programu SharePoint.
Właściwość HttpRequest.FilePath nie zawiera już wartości PathInfo
Poprzednie wersje ASP.NET zawierały wartość PathInfo w wartości zwróconej z różnych właściwości związanych ze ścieżką pliku, w tym HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath i HttpRequest.CurrentExecutionFilePath. ASP.NET 4 nie zawiera już wartości PathInfo w wartościach zwracanych z tych właściwości. Zamiast tego informacje PathInfo są dostępne w pliku HttpRequest.PathInfo. Załóżmy na przykład następujący fragment adresu URL:
/testapp/Action.mvc/SomeAction
We wcześniejszych wersjach ASP.NET właściwości HttpRequest mają następujące wartości:
HttpRequest.FilePath: /testapp/Action.mvc/SomeAction
HttpRequest.PathInfo: (pusty)
W ASP.NET 4 właściwości HttpRequest mają następujące wartości:
HttpRequest.FilePath: /testapp/Action.mvc
HttpRequest.PathInfo: SomeAction
ASP.NET 2.0 Aplikacje mogą generować błędy HttpException odwołujące się do elementu eurl.axd
Po włączeniu ASP.NET 4 w usługach IIS 6 ASP.NET 2.0 aplikacje działające w usługach IIS 6 (w systemie Windows Server 2003 lub Windows Server 2003 R2) mogą generować błędy, takie jak:
System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.
Ten błąd występuje, ponieważ gdy ASP.NET wykryje, że witryna sieci Web jest skonfigurowana do używania ASP.NET 4, natywny składnik ASP.NET 4 przekazuje bez rozszerzenia adres URL zarządzanej części ASP.NET do dalszego przetwarzania. Jeśli jednak katalogi wirtualne poniżej witryny sieci Web ASP.NET 4 są skonfigurowane do używania ASP.NET 2.0, przetwarzanie bez rozszerzenia adresu URL w ten sposób powoduje zmodyfikowany adres URL zawierający ciąg "eurl.axd". Ten zmodyfikowany adres URL jest następnie wysyłany do aplikacji ASP.NET 2.0. ASP.NET 2.0 nie może rozpoznać formatu "eurl.axd". W związku z tym ASP.NET 2.0 próbuje znaleźć plik o nazwie eurl.axd i wykonać go. Ponieważ taki plik nie istnieje, żądanie kończy się niepowodzeniem z wyjątkiem HttpException .
Ten problem można obejść przy użyciu jednej z następujących opcji.
Opcja 1
Jeśli ASP.NET 4 nie jest wymagane w celu uruchomienia witryny sieci Web, zamapuj ponownie witrynę, aby zamiast tego użyć ASP.NET 2.0.
Opcja 2
Jeśli ASP.NET 4 jest wymagane do uruchomienia witryny sieci Web, przenieś wszystkie katalogi wirtualne ASP.NET 2.0 do innej witryny sieci Web mapowanej na ASP.NET 2.0.
Opcja 3
Jeśli nie jest praktyczne ponowne mapowanie witryny sieci Web na ASP.NET 2.0 lub zmianę lokalizacji katalogu wirtualnego, jawnie wyłącz przetwarzanie bez rozszerzenia adresów URL w ASP.NET 4. Postępuj zgodnie z następującą procedurą:
- W rejestrze systemu Windows otwórz następujący węzeł:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0
- Utwórz nową wartość DWORD o nazwie EnableExtensionlessUrls.
- Ustaw wartość EnableExtensionlessUrls na wartość 0. Spowoduje to wyłączenie zachowania bez rozszerzenia adresu URL.
- Zapisz wartość rejestru i zamknij edytor rejestru.
- Uruchom narzędzie wiersza polecenia iisreset , co powoduje, że usługi IIS odczytują nową wartość rejestru.
Uwaga
Ustawienie wartości EnableExtensionlessUrls na 1 umożliwia zachowanie bez rozszerzenia adresu URL. Jest to ustawienie domyślne, jeśli nie określono żadnej wartości.
Programy obsługi zdarzeń mogą nie być wywoływane w dokumencie domyślnym w trybie zintegrowanym usług IIS 7 lub IIS 7.5
ASP.NET 4 zawiera modyfikacje, które zmieniają sposób renderowania atrybutu akcji elementu formularza HTML, gdy adres URL bez rozszerzenia jest rozpoznawany jako dokument domyślny. Przykładem bez rozszerzenia adresu URL rozpoznawania domyślnego dokumentu jest http://contoso.com/, co spowoduje żądanie do http://contoso.com/Default.aspx.
ASP.NET 4 renderuje teraz wartość atrybutu akcji elementu formularza HTML jako pusty ciąg po wysłaniu żądania do adresu URL bez rozszerzenia, który ma do niego zamapowany domyślny dokument. Na przykład we wcześniejszych wersjach ASP.NET żądanie http://contoso.com do żądania spowodowałoby żądanie do Default.aspx. W tym dokumencie tag formularza otwierającego zostanie renderowany tak, jak w poniższym przykładzie:
<form action="Default.aspx" />
W ASP.NET 4 żądanie http://contoso.com powoduje również żądanie do Default.aspx. Jednak ASP.NET teraz renderuje tag formularza otwierania HTML, jak w poniższym przykładzie:
<form action="" />
Ta różnica w sposobie renderowania atrybutu akcji może spowodować subtelne zmiany sposobu przetwarzania wpisu formularza przez usługi IIS i ASP.NET. Gdy atrybut akcji jest pustym ciągiem, obiekt DefaultDocumentModule usług IIS utworzy żądanie podrzędne do Default.aspx. W większości warunków to żądanie podrzędne jest niewidoczne dla kodu aplikacji, a Default.aspx strona działa normalnie.
Jednak potencjalna interakcja między kodem zarządzanym a usługami IIS 7 lub IIS 7.5 zintegrowanym może spowodować, że zarządzane strony aspx przestaną działać prawidłowo podczas żądania podrzędnego. Jeśli wystąpią następujące warunki, żądanie podrzędne do Default.aspx dokumentu spowoduje błąd lub nieoczekiwane zachowanie:
- Strona aspx jest wysyłana do przeglądarki z atrybutem akcjielementu formularza ustawionym na "".
- Formularz jest publikowany z powrotem do ASP.NET.
- Zarządzany moduł HTTP odczytuje część treści jednostki. Na przykład moduł odczytuje element Request.Form lub Request.Params. Powoduje to odczytanie treści jednostki żądania POST do pamięci zarządzanej. W związku z tym treść jednostki nie jest już dostępna dla żadnych modułów kodu natywnego uruchomionych w trybie zintegrowanym usług IIS 7 lub IIS 7.5.
- Obiekt DefaultDocumentModule usług IIS zostanie ostatecznie uruchomiony i utworzy żądanie podrzędne do
Default.aspxdokumentu. Jednak ponieważ treść jednostki została już odczytowana przez fragment kodu zarządzanego, nie ma dostępnej treści jednostki do wysłania do żądania podrzędnego. - Po uruchomieniu potoku HTTP dla
.aspxżądania podrzędnego program obsługi plików jest uruchamiany w fazie wykonywania programu obsługi. - Ponieważ nie ma treści jednostki, nie ma zmiennych formularza i nie ma stanu widoku, dlatego nie ma dostępnych informacji dla programu obsługi stron aspx w celu określenia, jakie zdarzenie (jeśli istnieje) ma zostać zgłoszone. W związku z tym żaden z procedur obsługi zdarzeń ogłaszania zwrotnego dla uruchomionego strony aspx, którego dotyczy problem.
To zachowanie można obejść w następujący sposób:
Zidentyfikuj moduł HTTP, który uzyskuje dostęp do treści jednostki żądania podczas domyślnych żądań dokumentów i określ, czy można go skonfigurować do uruchamiania tylko dla żądań zarządzanych. W trybie zintegrowanym dla usług IIS 7 i IIS 7.5 moduły HTTP można oznaczyć do uruchamiania tylko dla zarządzanych żądań, dodając następujący atrybut do wpisu system.webServer/modules modułu:
precondition="managedHandler"To ustawienie wyłącza moduł żądań, które usługi IIS 7 i IIS 7.5 określają jako żądania niezarządzane. W przypadku domyślnych żądań dokumentów pierwszym żądaniem jest adres URL bez rozszerzenia. W związku z tym usługi IIS nie uruchamiają żadnych zarządzanych modułów, które są oznaczone warunkiem wstępnym zarządzanego programu obsługi podczas początkowego przetwarzania żądań. W związku z tym moduły zarządzane nie będą przypadkowo odczytywać treści jednostki, dlatego treść jednostki jest nadal dostępna i jest przekazywana do żądania podrzędnego i do dokumentu domyślnego.
Jeśli problematyczne moduły HTTP muszą być uruchamiane dla wszystkich żądań (w przypadku plików statycznych, adresów URL bez rozszerzenia rozpoznawanych dla obiektu DefaultDocumentModule , dla żądań zarządzanych itp.), zmodyfikuj objęte strony właściwości Action kontrolki System.Web.UI.HtmlControls.HtmlForm na niepusty ciąg. Jeśli na przykład domyślny dokument to
Default.aspx, zmodyfikuj kod strony, aby jawnie ustawić właściwość Action kontrolki HtmlForm na wartość "Default.aspx".
Zmiany w implementacji zabezpieczeń dostępu kodu (CAS) ASP.NET
ASP.NET 2.0 i rozszerzą funkcje ASP.NET dodane w wersji 3.5, należy użyć modelu zabezpieczeń dostępu kodu (CAS) .NET Framework 1.1 i 2.0. Jednak wdrożenie cas w ASP.NET 4 zostało znacząco przebudowane. W związku z tym aplikacje oparte na zaufanym kodzie działającym w globalnej pamięci podręcznej zestawów (GAC) ASP.NET mogą zakończyć się niepowodzeniem z powodu różnych wyjątków zabezpieczeń. Aplikacje częściowo ufające, które opierają się na obszernych modyfikacjach zasad CAS maszyny, również mogą zakończyć się niepowodzeniem z wyjątkami zabezpieczeń.
Można przywrócić częściowe zaufanie ASP.NET 4 aplikacje do zachowania ASP.NET 1.1 i 2.0 przy użyciu nowego atrybutu legacyCasModel w elemecie konfiguracji zaufania , jak pokazano w poniższym przykładzie:
<trust level= "Medium" legacyCasModel="true" />
Po przywróconiu starszego modelu CAS są włączone następujące stare zachowania cas:
- Zasady cas komputera są honorowane.
- Dozwolone jest wiele różnych zestawów uprawnień w jednej domenie aplikacji.
- Jawne asercji uprawnień nie są wymagane dla zestawów w GAC, które są wywoływane, gdy tylko ASP.NET lub inny kod .NET Framework znajduje się na stosie.
Nie można przywrócić jednego scenariusza w .NET Framework 4: aplikacje nienależące do częściowego zaufania w sieci Web nie mogą już wywoływać niektórych interfejsów API w System.Web.dll i System.Web.Extensions.dll. W poprzednich wersjach .NET Framework można było jawnie przyznać aplikacjom niezawierającym częściowego zaufania sieci Web uprawnienia AspNetHostingPermission. Te aplikacje mogą następnie używać nazw System.Web.HttpUtility, typów w przestrzeniach nazw System.Web.ClientServices.* i typach związanych z członkostwem, rolami i profilami. Wywoływanie tych typów z aplikacji nienależących do sieci Web częściowego zaufania nie jest już obsługiwane w .NET Framework 4.
Uwaga
Funkcje HtmlEncode i HtmlDecode klasy System.Web.HttpUtility zostały przeniesione do nowej klasy .NET Framework 4 System.Net.WebUtility. Jeśli była to jedyna funkcja ASP.NET, która była używana, zmodyfikuj kod aplikacji, aby zamiast tego używał nowej klasy WebUtility .
Poniżej przedstawiono ogólne podsumowanie zmian w domyślnej implementacji cas w ASP.NET 4:
- ASP.NET domen aplikacji są teraz jednorodne domeny aplikacji. W domenie aplikacji są dostępne tylko zestawy udzielania z częściowym zaufaniem i pełnym zaufaniem.
- ASP.NET zestawy przyznawania częściowego zaufania są niezależne od zasad cas na poziomie przedsiębiorstwa, na poziomie komputera lub na poziomie użytkownika.
- ASP.NET zestawy dostarczone w wersji 3.5 i 3.5 SP1 zostały przekonwertowane w celu użycia modelu przezroczystości .NET Framework 4.
- Użycie atrybutu ASP.NET AspNetHostingPermission zostało znacznie zmniejszone. Większość wystąpień tego atrybutu została usunięta z publicznych interfejsów API ASP.NET.
- Dynamicznie kompilowane zestawy tworzone przez dostawców kompilacji ASP.NET zostały zaktualizowane w celu jawnego oznaczania zestawów jako przezroczystych.
- Wszystkie zestawy ASP.NET są teraz oznaczone w taki sposób, że atrybut APTCA jest honorowany tylko w środowiskach hostingu sieci Web. Częściowo zaufane środowiska hostingu nienależące do sieci Web, takie jak ClickOnce, nie będą mogły wywoływać ASP.NET zestawów.
Aby uzyskać więcej informacji na temat nowego modelu zabezpieczeń dostępu kodu ASP.NET 4, zobacz Using Code Access Security in ASP.NET Applications on the MSDN Web site (Używanie zabezpieczeń dostępu kodu w aplikacjach ASP.NET w witrynie sieci Web MSDN).
MembershipUser i inne typy w przestrzeni nazw System.Web.Security zostały przeniesione
Niektóre typy używane w członkostwie ASP.NET zostały przeniesione z System.Web.dll do nowego zestawu System.Web.ApplicationServices.dll. Typy zostały przeniesione w celu rozwiązania problemów z zależnościami warstw architektury między typami w kliencie i rozszerzonymi jednostkami SKU .NET Framework.
Projekty witryn sieci Web nie mają problemów w wyniku przeniesienia tych typów, ponieważ System.Web.ApplicationServices.dll został dodany do listy zestawów, do których odwołania są używane domyślnie przez system kompilacji ASP.NET. Jeśli uaktualnisz projekt witryny sieci Web, który został utworzony przy użyciu wcześniejszej wersji ASP.NET do ASP.NET 4, otwierając go w programie Visual Studio 2010, projekt zostanie skompilowany bez błędów.
Podobnie, jeśli uaktualnisz projekt aplikacji internetowej, który został utworzony we wcześniejszej wersji ASP.NET do ASP.NET 4, otwierając go w programie Visual Studio 2010, proces uaktualniania dodaje odwołanie do System.Web.ApplicationServices.dll do projektu. W związku z tym uaktualnione projekty aplikacji internetowych będą również kompilowane bez błędów.
Skompilowane (binarne) pliki utworzone przy użyciu wcześniejszych wersji ASP.NET będą również uruchamiane bez błędów w ASP.NET 4, mimo że typy członkostwa zostały przeniesione do innego zestawu. Dodano informacje przekazujące typy do wersji ASP.NET 4 System.Web.dll , która automatycznie kieruje odwołania do czasu wykonywania dla tych typów do nowej lokalizacji dla typów.
Jednak biblioteki klas korzystające z określonych typów członkostwa i uaktualnione z wcześniejszych wersji ASP.NET nie będą kompilowane w przypadku użycia w projekcie ASP.NET 4. Na przykład kompilacja projektu biblioteki klas może zakończyć się niepowodzeniem i zgłosić błąd, taki jak:
The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.
Ten problem można obejść, dodając odwołanie w projekcie biblioteki klas do System.Web.ApplicationServices.dll.
Na poniższej liście przedstawiono typy System.Web.Security , które zostały przeniesione z System.Web.dll do System.Web.ApplicationServices.dll:
- System.Web.Security.MembershipCreateStatus
- System.Web.Security.Membership.CreateUserException
- System.Web.Security.MembershipPasswordException
- System.Web.Security.MembershipPasswordFormat
- System.Web.Security.MembershipProvider
- System.Web.Security.MembershipProviderCollection
- System.Web.Security.MembershipUser
- System.Web.Security.MembershipUserCollection
- System.Web.Security.MembershipValidatePasswordEventHandler
- System.Web.Security.ValidatePasswordEventArgs
- System.Web.Security.RoleProvider
- System.Web.Configuration.MembershipPasswordCompatibilityMode
Zmiany buforowania danych wyjściowych w różnych * nagłówek HTTP
W ASP.NET 1.0 usterka spowodowała buforowane strony określone Location="ServerAndClient" jako ustawienie wyjściowej pamięci podręcznej w celu emitowania Vary:* nagłówka HTTP w odpowiedzi. Miało to wpływ na informowanie przeglądarek klienckich, aby nigdy nie buforowały strony lokalnie.
W ASP.NET 1.1 dodano metodę System.Web.HttpCachePolicy.SetOmitVaryStar , którą można wywołać, aby pominąć Vary:* nagłówek. Ta metoda została wybrana, ponieważ zmiana emitowanego nagłówka HTTP została uznana za potencjalnie powodującą niezgodność zmianę w tym czasie. Jednak deweloperzy byli zdezorientowani zachowaniem w ASP.NET, a raporty o błędach sugerują, że deweloperzy nie wiedzą o istniejącym zachowaniu SetOmitVaryStar .
W ASP.NET 4 podjęto decyzję o rozwiązaniu głównego problemu. Vary:* Nagłówek HTTP nie jest już emitowany z odpowiedzi, które określają następującą dyrektywę:
<%@OutputCache Location="ServerAndClient" %>
W związku z tym funkcja SetOmitVaryStar nie jest już potrzebna, aby pominąć Vary:* nagłówek.
W aplikacjach, które określają Location="ServerAndClient" w dyrektywie @ OutputCache na stronie, zobaczysz zachowanie sugerowane przez nazwę wartości atrybutu Location — oznacza to, że strony będą buforowane w przeglądarce bez konieczności wywoływania metody SetOmitVaryStar .
Jeśli strony w aplikacji muszą emitować Vary:*metodę , wywołaj metodę AppendHeader , jak w poniższym przykładzie:
HttpResponse.AppendHeader("Vary","*");
Alternatywnie można zmienić wartość wyjściowego buforowania atrybutu Location na "Serwer".
Typy System.Web.Security dla usługi Passport są przestarzałe
Obsługa usługi Passport wbudowana w ASP.NET 2.0 jest przestarzała i nieobsługiwana od kilku lat ze względu na zmiany w usłudze Passport (obecnie LiveID). W rezultacie pięć typów powiązanych z usługą Passport w pliku System.Web.Security jest teraz oznaczonych atrybutem ObsoleteAttribute .
Właściwość MenuItem.PopOutImageUrl nie może renderować obrazu w ASP.NET 4
W ASP.NET 3.5 właściwość MenuItem.PopOutImageUrl umożliwia określenie adresu URL obrazu wyświetlanego w elemencie menu, aby wskazać, że element menu ma dynamiczny podmenu. W poniższym przykładzie pokazano, jak określić tę właściwość w znacznikach w ASP.NET 3.5.
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
PopOutImageUrl="~/Images/Popout.gif"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
PopOutImageUrl="~/Images/Popout.gif"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
W wyniku zmiany projektu w ASP.NET 4 żadne dane wyjściowe nie są renderowane dla elementu PopOutImageUrl , jeśli właściwość jest ustawiona dla klasy MenuItem . Zamiast tego należy określić adres URL obrazu bezpośrednio w kontrolce Menu przy użyciu właściwości StaticPopOutImageUrl lub właściwości DynamicPopOutImageUrl . Podczas pracy z menu statycznym właściwość Menu.StaticPopOutImageUrl określa adres URL obrazu wyświetlanego w celu wskazania, że element menu statycznego ma podmenu, jak pokazano w poniższym przykładzie:
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Jeśli pracujesz z menu dynamicznym, użyj właściwości Menu.DynamicPopOutImageUrl , aby określić adres URL obrazu, który wskazuje, że dynamiczny element menu ma podmenu. Poniższy przykład jest podobny do poprzedniego, ale pokazuje, jak ustawić właściwość DynamicPopOutImageUrl dla menu dynamicznego.
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
DynamicPopOutImageTextFormatString="More..."
DynamicPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Jeśli właściwość Menu.DynamicPopOutImageUrl nie jest ustawiona, a właściwość Menu.DynamicEnableDefaultDefaultPopOutImage ma wartość false, nie zostanie wyświetlony żaden obraz. Podobnie jeśli właściwość StaticPopOutImageUrl nie jest ustawiona, a właściwość StaticEnableDefaultDefaultPopOutImage ma wartość false, nie jest wyświetlany żaden obraz.
Po ustawieniu ścieżek dla tych właściwości użyj ukośnika (/) zamiast ukośnika odwrotnego (). Aby uzyskać więcej informacji, zobacz Menu.StaticPopOutImageUrl i Menu.DynamicPopOutImageUrl nie mogą renderować obrazów, gdy ścieżki zawierają ukośniki odwrotne w innym miejscu w tym dokumencie.
Menu.StaticPopOutImageUrl i Menu.DynamicPopOutImageUrl nie można renderować obrazów, gdy ścieżki zawierają ukośniki odwrotne
W ASP.NET 4 obrazy określone przy użyciu właściwości Menu.StaticPopImageUrl i Menu.DynamicPopOutImageUrl nie będą renderowane, jeśli ścieżka zawiera ukośnika odwrotne (). Jest to zmiana z wcześniejszych wersji ASP.NET.
Poniższy przykład znaczników kontrolki Menu przedstawia właściwość StaticPopOutImageUrl ustawioną przy użyciu ścieżki zawierającej ukośnik odwrotny. W ASP.NET 4 obraz określony we właściwości nie będzie renderowany.
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images\Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Aby rozwiązać ten problem, zmień wartości ścieżki, które są określone we właściwościach StaticPopOutImageUrl i DynamicPopOutImageUrl , aby używać ukośników do przodu (/). W poniższym przykładzie przedstawiono tę zmianę:
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Należy pamiętać, że na aplikacje migrowane z wcześniejszych wersji ASP.NET do ASP.NET 4 mogą również mieć wpływ, ponieważ właściwość MenuItem.PopOutImageUrl została zmieniona. Aby uzyskać więcej informacji, zobacz nie może renderować obrazu w ASP.NET 4 w innym miejscu w tym dokumencie.
Disclaimer
Jest to wstępny dokument i może zostać znacząco zmieniony przed ostateczną komercyjną wersją oprogramowania opisanego w niniejszym dokumencie.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Ponieważ firma Microsoft musi reagować na zmieniające się warunki rynkowe, nie powinna być interpretowana jako zobowiązanie ze strony firmy Microsoft, a firma Microsoft nie może zagwarantować dokładności wszelkich informacji przedstawionych po dacie publikacji.
Ta biała księga jest przeznaczona tylko do celów informacyjnych. FIRMA MICROSOFT NIE UDZIELA ŻADNYCH GWARANCJI, WYRAŹNYCH, DOMNIEMANYCH ANI USTAWOWYCH, CO DO INFORMACJI W TYM DOKUMENCIE.
Przestrzeganie wszystkich obowiązujących praw autorskich jest obowiązkiem użytkownika. Bez ograniczania praw autorskich żadna część tego dokumentu nie może być odtwarzana, przechowywana w systemie pobierania lub przekazywana w jakiejkolwiek formie lub w jakikolwiek sposób (elektroniczna, mechaniczna, mechaniczna, nagrywana lub w inny sposób) lub do żadnego celu, bez wyraźnego pisemnego zezwolenia firmy Microsoft Corporation.
Firma Microsoft może mieć patenty, wnioski patentowe, znaki towarowe, prawa autorskie lub inne prawa własności intelektualnej obejmujące tematy w tym dokumencie. Z wyjątkiem wyraźnie podanych w jakiejkolwiek pisemnej umowie licencyjnej od firmy Microsoft, wyposażenie tego dokumentu nie daje żadnych licencji na te patenty, znaki towarowe, prawa autorskie lub inną własność intelektualną.
O ile nie określono inaczej, przykładowe firmy, organizacje, produkty, nazwy domen, adresy e-mail, logo, osoby, miejsca i wydarzenia przedstawione w niniejszym dokumencie są fikcyjne, a żadne skojarzenie z żadną rzeczywistą firmą, organizacją, produktem, nazwą domeny, adresem e-mail, logo, osobą, miejscem lub wydarzeniem jest zamierzone lub powinny być wnioskowane.
© 2010 Microsoft Corporation. All rights reserved.
Firmy Microsoft i Windows są zarejestrowanymi znakami towarowymi lub znakami towarowymi firmy Microsoft Corporation w Stany Zjednoczone i/lub innych krajach.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla