- pityulaman1983 blogja
- A hozzászóláshoz be kell jelentkezni
- 1447 megtekintés
Hozzászólások
Azt hittuk erdekes blog lesz teszten mukodott elesben nem...
:D
- A hozzászóláshoz be kell jelentkezni
Azért az eredményről beszámoljak? :)
-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Kódhibát kizárnám, mert "Teszten működik, élesen nem"
Mellesleg kb 20 sor az egész, ráadásul egy SSIS package-ben lévő Scipt component-ről van szó.
-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"
- A hozzászóláshoz be kell jelentkezni
"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™
- A hozzászóláshoz be kell jelentkezni
Ez jó hír, ebben az esetben a topiknyitó kolléga problémája is csak képzeletbeli. Vagy csoda történt.
- A hozzászóláshoz be kell jelentkezni
Értem, tehát ha A helyen valami megy és B helyen valami nem, akkor csak nem inicializált változó miatt lehet.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
És az iróniadetektorban lemerült az akksi... :)
- A hozzászóláshoz be kell jelentkezni
Egyértelműen.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
ASP.NET épít a Newtonsoft.JSON-ra már elég régóta.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
De ez nem ASP.NET :)
-----------
Akkor beszélsz igazán jól angolul, ha egy angol viccen őszintén tudsz nevetni
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni