zarchiwizowany
Skomentuj
(31)
Pobierz ten tekst w formie obrazka
Shadow85
Niechcący piekielnym okazał się kolega z firmy. Piekielnym bo już tam nie pracuje, a ja jako specjalista od wszelakich nowinek technologicznych przejąłem po nim jeden z projektów.
Musiałem rozwinąć aplikację webową, która do połączeń z bazą danych korzystała z WebService. Prościzna, pisana przy pomocy VisualStudio w C#. Problem pojawił się kiedy została wrzucona testowo do sieci. Po prostu nie działa. Próbuję się zalogować i dostaję komunikat nie ma takiej strony.
Próby debugowania IIS spełzły na niczym. W Windows 7 nie ma bezpośrednio procesu odpowiedzialnego za serwer, pod który można by się było podpiąć. Przy sprawdzeniu co nasłuchuje na porcie 80 wychodzi, że jest to "System". Czyli jak to się nie ładnie mówi pupa... Nasłuchiwanie pakietów sieciowych też spełzło na niczym, zapytanie jest, odpowiedzi brak.
Dopiero po jakimś czasie, zorientowałem się, że tak na prawdę nie wywala się strona czy webservice, ale całe Application Pool, co jest równoznaczne z rozsypką serwera www. Cały kod opakowany blokiem przechwytującym wyjątki, które miały być odpowiednio zwracane i zapisywane do pliku tekstowego. Nawet do tej części kodu nie wchodziło.
Zaczynają się testy na piechotę, umieszczanie w odpowiednich miejscach wyjątków i sprawdzanie, do którego momentu tak na prawdę dochodzi całe to wywołanie. Jest! DllImport, czyli wywołanie osobnej biblioteki. Żeby było śmieszniej, w WebServerze VisualStudio wszystko pięknie ładnie działa, po wrzuceniu do IIS są problemy z jej wywołaniem (na pewno była ładowana bo po zmianie nazwy, dostawałem błąd o braku pliku), ki czort?
DLL napisana w delphi. Najprawdopodobniej problem ze współdzieloną pamięcią, trudno. Z całą pierdołą walczyłem ponad 8h przy wsparciu starszego stażem kolegi. W akcje desperacji zaglądam na środowisko produkcyjne gdzie teoretycznie to rozwiązanie działa...
Na środowisku produkcyjnym nawet nie ma tego DLL, okazało się, że ta część aplikacji nigdy nie działała, gdyż przy ustawieniach produkcyjnych, nigdy nie jest wywoływana ta metoda... a wszystko dzięki koledze, który najwidoczniej nie uznał za stosowne dodanie, krótkiej informacji na ten temat... Microsoft też dodał swoje 3 grosze brakiem logicznych komunikatów i obsługi błędów...
Jeżeli zrozumiałeś cokolwiek z tej historii powinieneś częściej wychodzić z domu :)
Musiałem rozwinąć aplikację webową, która do połączeń z bazą danych korzystała z WebService. Prościzna, pisana przy pomocy VisualStudio w C#. Problem pojawił się kiedy została wrzucona testowo do sieci. Po prostu nie działa. Próbuję się zalogować i dostaję komunikat nie ma takiej strony.
Próby debugowania IIS spełzły na niczym. W Windows 7 nie ma bezpośrednio procesu odpowiedzialnego za serwer, pod który można by się było podpiąć. Przy sprawdzeniu co nasłuchuje na porcie 80 wychodzi, że jest to "System". Czyli jak to się nie ładnie mówi pupa... Nasłuchiwanie pakietów sieciowych też spełzło na niczym, zapytanie jest, odpowiedzi brak.
Dopiero po jakimś czasie, zorientowałem się, że tak na prawdę nie wywala się strona czy webservice, ale całe Application Pool, co jest równoznaczne z rozsypką serwera www. Cały kod opakowany blokiem przechwytującym wyjątki, które miały być odpowiednio zwracane i zapisywane do pliku tekstowego. Nawet do tej części kodu nie wchodziło.
Zaczynają się testy na piechotę, umieszczanie w odpowiednich miejscach wyjątków i sprawdzanie, do którego momentu tak na prawdę dochodzi całe to wywołanie. Jest! DllImport, czyli wywołanie osobnej biblioteki. Żeby było śmieszniej, w WebServerze VisualStudio wszystko pięknie ładnie działa, po wrzuceniu do IIS są problemy z jej wywołaniem (na pewno była ładowana bo po zmianie nazwy, dostawałem błąd o braku pliku), ki czort?
DLL napisana w delphi. Najprawdopodobniej problem ze współdzieloną pamięcią, trudno. Z całą pierdołą walczyłem ponad 8h przy wsparciu starszego stażem kolegi. W akcje desperacji zaglądam na środowisko produkcyjne gdzie teoretycznie to rozwiązanie działa...
Na środowisku produkcyjnym nawet nie ma tego DLL, okazało się, że ta część aplikacji nigdy nie działała, gdyż przy ustawieniach produkcyjnych, nigdy nie jest wywoływana ta metoda... a wszystko dzięki koledze, który najwidoczniej nie uznał za stosowne dodanie, krótkiej informacji na ten temat... Microsoft też dodał swoje 3 grosze brakiem logicznych komunikatów i obsługi błędów...
Jeżeli zrozumiałeś cokolwiek z tej historii powinieneś częściej wychodzić z domu :)
Opowieści programistyczne
Ocena:
27
(131)
Komentarze