Przy przenoszeniu aplikacji z maszyny testowej na środowisko produkcyjne zawsze pojawiają się jakieś problemy (zwykle drobne - jak w opisywanym przypadku). Czas leci a w myślach "WTF?"...
Do testów aplikacji służyły nam komputery z XP mające IIS 5.1. Na produkcji zainstalowano jednak Windows 2003 z IIS 6.0. Po skopiowaniu wszystkiego co potrzeba i skonfigurowaniu katalogów wirtualnych okazało się, że można uzyskać dostęp jedynie do statycznych stron np. *.html. Przy próbie otwarcia strony *.aspx serwer odpowiadał kodem 404. U nas działo a tutaj nie chce... Przyczyna okazała się bardzo prosta: domyślnie po instalacji rozszerzenie IIS ASP.NET v2.0 miało status ustawiony na "Prohibited". Aby dynamiczny content ASPX mógł być serwowany to ustawienie musi zostać zmienione na "Allowed".
Kroki potrzebne do rozwiązania problemu:
- Uruchom konsole IIS (inetmgr.exe)
- Po lewej stronie konsoli zaznacz interesujący Cię serwer
- Kliknij węzeł "Web Service Extensions" (po prawej stronie okna pokaże się lista dostępnych rozszerzeń)
- Zaznacz na liście nazwę rozszerzenia odpowiedzialnego za wersję ASP.NET, z której korzysta Twoja aplikacja
- Naciśnij przycisk "Allow"
I to tyle! Superproste (jeśli wiesz o tym).
Podczas korzystania z kontrolki CheckBox i ustawiania jej po stronie klienta jako nieaktywnej, natchnąłem się na problem, który (przeoczony) może sporo namieszać w pracy aplikacji. Otóż jeśli CheckBox jest zaznaczony i zablokujesz go ustawiając właściwość disabled w JavaScript to po postbacku zobaczysz, że właściwość Checked == false!
Ten fragment JS ustawia właściwość disabled (CheckBox staje się szary i przestaje reagować na akcje użytkownika):
document.getElementById('<%= CheckBox1.ClientID %>').disabled = true;
Po "powrocie na serwer" kontrolka CheckBox nie będzie zaznaczona. Dzieje się tak dlatego, że przeglądarka nie wysyła w requescie informacji o polu input type="checkbox" z atrybutem disabled.
Testowałem w IE6/8 i FF2 na .NET 2.0/3.5.
Zaletą pisania aplikacji intranetowych jest często to, że wszyscy użytkownicy programu będą korzystać z identycznej przeglądarki. Niestety w wielu instytucjach tą przeglądarką jest IE6. Niechęć do zmiany przeglądarki wynika często z obaw o to, że stare aplikacje (krytyczne dla działalności) nie będą pracować w nowszym IE...
Jeśli w budowanym rozwiązaniu zamierzasz użyć Ajaxa nie zapomnij w wymaganiach warstwy klienckiej określonych w umowie, dodać obsługę ActiveX. Dlaczego nie wystarczy włączyć JavaScript? W IE5.x i IE6 za obsługę asynchronicznej komunikacji z serwerem odpowiada obiekt ActiveX. Utworzyć go można w taki sposób:
var xhr = new ActiveXObject('Microsoft.XMLHTTP');
W innych przeglądarkach obiekt XmlHttpRequest tworzony jest za pomocą kodu:
var xhr = new XMLHttpRequest();
więc użycie ActiveX nie jest konieczne (dotyczy to także IE7).
Jeśli myślisz, że możesz nie przejmować się IE6 to niestety jesteś w błędzie. Ta przestarzała (wypuszczona w 2001) przeglądarka ma nadal 30% udziału w rynku internetowym. W intranetach firm i urzędów na pewno nie jest lepiej...
Gdy w VS 2008 przeciągasz kontrolki z Toolboxa na widok strony (działając w trybie Design) są one pozycjonowane wierszami (nie możesz przeciągnąć ich w dowolny obszar strony). By zmienić tryb pozycjonowania dla jednej kontrolki musisz ją zaznaczyć i skorzystać z opcji menu "Format | Position...".
A co jeśli chciałbyś ustawić środowisko w taki sposób by każda przeciągana z palety narzędzi kontrolka była domyślnie pozycjonowana absolutnie? W wersji 2005 służyła do tego odpowiednia opcja menu "Layout". Aby wprowadzić to ustawienie w najnowszej wersji Visual Studio trzeba poszukać głębiej...
Wybierz "Tools | Options...", w otwartym oknie zaznacz checkboxa "Show all settings", wybierz kategorie "HTML Designer | CSS Styling" i zaznacz checkboxa "Change positioning to absolute for controls added using Toolbox, paste or drag and drop". Gotowe!
Pamiętaj tylko, że do przeciągania elementów na stronie służy mała etykietka, która pojawia się po zaznaczeniu kontrolki.
Dzięki funkcji parseInt() języka JavaScript w łatwy sposób można dokonać konwersji łańcucha tekstowego na liczbę całkowitą. Niestety korzystanie z niej w celu pobrania wartości wpisanej przez użytkownika niesie za sobą pewne zagrożenie. Przeanalizuj poniższy fragment kodu:
function dodaj() {
var txt = document.getElementById('TextBox1');
var a = parseInt(txt.value);
return a + 10;
}
Co stanie się gdy użytkownik wprowadzi do okienka 10? Oczywiście funkcja zwróci wartość 20. Co jednak wydarzy się gdy ktoś wpisze do okienka ciąg 010? Otóż w rezultacie otrzymamy 18! Stało się tak dlatego, że funkcja parseInt() wywoływana tylko z jednym parametrem zinterpretowała tekst wpisany przez usera aplikacji jako wartość podaną w systemie ósemkowym (napis postaci 0x10 został by odczytany jako szesnastkowy). Możesz być niemal pewien, iż użytkownik programu zakładał, że wprowadzenie zera przed liczbę nie powinno mieć wpływu na wynik. A jednak ma! Co zrobić by program działał bardziej intuicyjnie? Wystarczy dodać w wywołaniu funkcji parseInt() drugi parametr określający podstawę wykorzystywanego systemu liczbowego. Należy więc zastosować taki kod:
function dodaj2() {
var txt = document.getElementById('TextBox1');
var a = parseInt(txt.value, 10);
return a + 10;
}