Teszten működik, élesen nem

A bejegyzés a nyugalom megzavarására alkalmas szöveget tartalmazhat!
Csak akkor olvasd tovább, ha engem és a Microsoft technológiákat nem irtanád tűzzel-vassal!
---------------------------------------------------------------------

Alapvetően egy ilyen művelet (mármint, amit most csinálok) alsó hangon 3 év fejlövés, de nem tudok jobbat. .NET Framework-öt nem igazán vértezték fel JSON Serialize és Deserialize függvényekkel, ezért 3rd partyként a mindenki által javasolt Newton Soft JSON parserét kötöttem be referenciaként. Eredmény: teszten működik, élesen nem.
Hogy mi a hiba oka, azt inkább hagyjuk. Nem reprodukálható, a hibaüzenet nagyjából a semmi és a nulla között helyezkedik el félúton. A teszt egy darab szerver, az éles egy cluster. Teszten működik, élesen nem. Minden próbálkozás 1-1 telepítés a rengeteg sallanggal egyetemben. Három töltényed van, ebből kettő vak, egy éles. Teszten működik, élesen nem. Egy webservice-t hívok meg kétszer, egyszintű, pofon egyszerű választ várok. Teszten működik, élesen nem. Hogy megkíméljem magunkat rengeteg extra szívástól, úgy döntöttem, kidobom a 3rd party parserét. Teszten működik, élesen nem. Átírom egyszerű string műveletekre. Nem vagyok büszke rá, nem szép megoldás, pláne nem 1x év tapasztalattal mögöttem. Teszten működik, élesen nem. Remélem teszten működni fog és élesen is.
Update: Teszten működik és az élesen is :)

Hozzászólások

Azt hittuk erdekes blog lesz teszten mukodott elesben nem...

:D

Lehet, hogy az inicializálatlan változó (vagy egyéb optimalizációtól/debugtól/holdállástól függően működő rész) nem ott van, ahol gondolod, hogy van.

"Lehet, hogy az inicializálatlan változó"

Szeretném felhívni a C-n meg mindenféle hulladék scriptnyelveken (JavaScript, PHP, ilyesmik) nevelkedettek figyelmét arra, hogy normális nyelven le sem fordul az a kód, amiben nem inicializált változó van. (Vagy nem az a néhány kivételes eset van, amikor explicit megmondja a nyelv specifikációja, hogy mi a default érték.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ideértve az 'á ezzel nem kell törődni' tipusú beállításokat, amilyen pl. a LC_CTYPE vagy a 'Vezérlőpult / Terület és nyelv / Felügyelet / Unicode szabványt nem támogató programok nyelve'.

PS: ja és azt tudni kell, hogy a látszólag helyes működés nem a program hibátlanságát bizonyítja, csak azt, hogy a hibák száma páros.

Off.
Valóban aktív koromban szerettem az ilyen dolgokat. Nem mondom, mire megoldódtak, addigra már legalább háromszor adtam be a felmondásomat, de mindig marhanagy sikerélmény volt mikor kiderült, mi okozza a látszólag lehetetlen (nem)működést.

Maradandó élményem egy ilyen volt: Oracle rman backupból visszatöltés "nem működött". :D (én voltam a hülye... meg az indiai supportos is)

Nem vagyok .NET fejlesztő, de tanulva mások tapasztalataiból, egy Debug build-et érdemes megnézni.

".NET Framework-öt nem igazán vértezték fel JSON Serialize és Deserialize függvényekkel"
Ezt először nehezen hittem, elvégre egy rakás MS cucc épít így vagy úgy JSON-ra. Pl. ott a PowerShell ConvertFrom-Json és ConvertTo-Json cmdletje. Ha már úgyis kinn van GitHubon, gondoltam megnézem a forrást. Úgy tűnik tényleg nincs built-in megoldás...

Nos, elég banális a hiba oka.
A dll-t global assembly cache-be beregisztráltuk a teszt szerveren. Viszont az éles szerver korábbi verzió, ott még nem létezett GAC, így azt referenciaként behúzni sem tudta.

-----------
Akkor beszélsz igazán jól angolul, ha egy angol viccen őszintén tudsz nevetni