Kiedyś pisałem o tym, że wkurza mnie hackowanie. Teraz zaś zmarnowałem dosłownie 3h życia na niczym. Nie znoszę tego uczucia, bo przez ten czas mógłbym zrobić wiele. Teraz te 3h będę musiał nadrobić a to jest jeszcze gorsze. A zmarnowałem to niby na programowaniu. Tylko programowanie, programowaniu nie równe. To co jest poniżej, to mały rant, ale między wierszami można przeczytać co jest i/lub było nie tak.

Jedyna rzecz która wkurza mnie w całym programowaniu, to nie programowanie, a cały ekosystem wokół, który zamiast umożliwić mi pracę, rzuca kłody pod nogi. Czytasz ten post o 8 rano, 23 marca. Powstaje on o 17:00 22 marca. Moje ostatnie 3 godziny spędziłem na naprawianiu błędu:

guidance.cshtml(2): error CS0103: The name 'ViewBag' does not exist in the current context

Który pojawił się jedynie na środowisko staging. Na lokalnym, testowym i live, tego błędu nie było.

Cały stack trace:

System.Web.HttpCompileException (0x80004005): DRIVE_LETTER:\PATH\guidance.cshtml(2): error CS0103: The name 'ViewBag' does not exist in the current context
   at System.Web.Compilation.AssemblyBuilder.Compile()
   at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
   at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound)
   at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp)
   at System.Web.WebPages.BuildManagerWrapper.CreateInstanceOfType[T](String virtualPath)
   at System.Web.WebPages.VirtualPathFactoryManager.CreateInstanceOfType[T](String virtualPath)
   at System.Web.WebPages.WebPageHttpHandler.CreateFromVirtualPath(String virtualPath, IVirtualPathFactory virtualPathFactory)
   at System.Web.WebPages.WebPageRoute.DoPostResolveRequestCache(HttpContextBase context)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Zero info w Event Logach. Wszystkie inne strony działały poprawnie, tylko ta jedna wywoływała błąd i tylko na jednym środowisku.

Pierwsza myśl? Zły deployment. Re-deploymentu nie przyniósł rezultatu. Restart IIS, app pool też nie. Kolejna próba (po restarcie) deploymentu też nic nie dała.

Na wszelki wypadek prześledziłem Stackoverflow i zrobiłem wszystko co oni tam mówili, zweryfikowałem Web.config, oraz web.cofnig of views. Wszystko poprawnie.

Usunąłem wszystkie odwołania do ViewBag z guidance.cshtml i z _layouts.cshtml, to na tej jednej stronie dostałem wyjątek ale o dziwno nLog go nie zalogował. W sensie mam tylko swój tekst przy niewyłapanych wyjątkach:

Thread: 71 | User: auth:XXXX | PipelineStepManager.ResumeSteps => HttpApplication.RaiseOnError => MvcApplication.Application_Error
 Unhandled error

Zero stack trace. Coś jest naprawdę nie tak.

Z braku laku, zacząłem usuwać wszystkie pliki temp, w tym także:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Dalej nic. Wszystkie inne strony działają tylko ta jedna nie chce.

Na wkurzeniu zrobiłem kolejny deployment (ten sam deployment tego samego kodo co przez ostatnie 3h)…

I nagle zadziałało.

Tak z siebie. Od tak. Teraz, bądź tu mądry. Co było nie tak? Czemu to nie działało? Gdzie był błąd?

NIE WIEM. A co gorsza, nic nie robiąc kod zaczął działać. Takie rzeczy mnie najbardziej ze wszystkich wkurzają. I niektórzy nazwali by mnie głupcem albo szaleńcem:

Insanity: doing the same thing over and over again and expecting different results.
Einstein (choć nie jest to pewne)

A jednak, po raz kolejny, przy MVC .NET powtarzanie tego samego w kółko i oczekiwanie innego rezultatu się sprawdza.

Nie życzę nikomu takiego programowania bo to zniechęca a nie zachęca do tego by coś robić.

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

12 KOMENTARZE

  1. Co jest gorsze od “nie działa i nie wiem dlaczego” ?
    “Działa i nie wiem dlaczego” :D

  2. Rany, ilekrotnie takie coś przeżywałem, zwłaszcza na etapie poznawania technologii i / lub framwerorków.

    chocby wczoraj, pisze sobie routing do react-redux i czemu to cholerstwo nie działa.. okazało się, ze po prostu na podstawie tutoriali pisałem przestarzały kod. wystarczyło 5min roboty, by rozwiązać 4.godzinny maraton wkurzania czemu to nie działa.

    damn.

  4. Takie błędy wkurzają i to mocno. Ale mnie wkurzają inne błędy.
    Błędy, które pochodzą z trzecich bilbiotek. Używam jakieś bilbioteki z nugeta, wszystko bangla, mały update i nagle “coś przestaje działać”.
    Dla mnie kłopotliwy był ostatnio update .net core do 1.1.1 w moich obrazach docker’a. Nie do końca działało od razu z SDK. Kilka godzin zeszło, zanim naprawiłem wszystko.

  5. Teoria jest wtedy, kiedy wiemy wszystko, a nic nie działa.
    Praktyka jest wtedy, kiedy wszystko działa, a nikt nie wie dlaczego.
    W tym przypadku (dawniej – na Politechnice) łączymy teorię z praktyką. Nic nie działa i nikt nie wie dlaczego.

  6. To prawda, są to bardzo zniechęcające problemy. Zwłaszcza jak nie można ich zreprodukować. Bądź mądry i zgadnij czy build server coś napsioczył, czy może webserver odwoływał się cały czas do plikow z shadow copy.

  7. To co napisałeś oczywiście jest wkurzające, ale dla mnie wczorajszy błąd był o wiele gorszy. Napisałem program który WinRM wysyła coś na zdalny komputer i uruchamia. Testuję – “u mnie działa”. Wysyłam koledze – u niego nie działa. Sprawdzamy testujemy, zmieniam, poprawiam, wysyłam mu paczki chyba ze 20 razy. Zmieniamy konfiga, podaje w konfigu moje loginy i hasła -NIC. W końcu przyjechałem do siedziby i podszedłem do jego kompa… On uruchamiał ten program na tym hoście do którego miał wysyłać paczkę. A mieliśmy różne dziwne błędy, które za cholerę na to nie wskazywały, a ja się nie spodziewałem, że on uruchamia program wysyłający paczki na host zdalny na tym zdalnym hoście :) Co najmniej 5 godzin w plecy. Wyobraź sobie jak wyglądałem na daily :(

  8. Kilka lat pracy z SharePointem uświadomiły mi, że to powiedzenie o szaleństwie się do niego nie odnosi.
    Trochę smutne jest też to, że gdy nie wiemy o co chodzi zawsze wykonujemy podobny zestaw czynności:
    redeployment, restart IIS, czyszczenie plików tymczasowych, web config….
    Widzę tu pewne pole do optymalizacji:)
    Na szczęście przygodę z SharePointem mam już za sobą:)

Comments are closed.