Weblog @ Rebex.cz :: Honza Šotola

Číslování týdnů v .NETu

honzas — Wed, 27 Jan 2010 08:48:00 GMT

V letošním roce je (opět) patrné, že .NET používá jiné číslování týdnů, než je standardizováno v České republice.
Upozornil nás na to klient, jehož aplikace letos používala čísla týdnů o jedno vyšší, než podle papírového kalendáře, přestože vloni fungovala správně.

Jak to má být:

V ČR se pro reprezentaci času používá (stejně jako ve většine Evropy) norma ISO 8601 (v ČR převzatá jako ČSN ISO 8601) a podle té je první týden v roce takový, který obsahuje 4. leden.

Jak to je:

Číslo týdne pro zvolené datum se v .NETu získá metodou
Calendar.GetWeekOfYear(datum, weekRule, firstDayOfWeek).
Instanci třídy Calendar získáme např. z CultureInfo.CurrentCulture.Calendar.

Problém je právě v tom, odkud dodat hodnotu parametrů weekRule (pravidlo pro číslování týdnů). Rozumné by bylo převzít ho z aktuálního regionálního nastavení, tedy z
CultureInfo.CurrentCulture.DateTimeFormat.CalendarWeekRule.
Bohužel, ta pro českou kulturu (cs-CZ) vrací hodnotu FirstDay (tedy číslování se začíná v týdnu, který obsahuje první leden).

Tedy zápis

CultureInto.CurrentCulture.Calendar.GetWeekOfYear( datum, CultureInfo.CurrentCulture.DateTimeFormat.CalendarWeekRule, CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek).

nevrátí číslo týdne, platné v ČR.

Jak to řešit:

Natvrdo (resp. po ověření, že aktuální CultureInfo je české) používat hodnotu CalendarWeekRule.FirstFourDayWeek.

Správné číslo týdne tedy vrátí výraz

CultureInto.CurrentCulture.Calendar.GetWeekOfYear( datum, CalendarWeekRule.FirstFourDayWeek, CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek)

Poznámka:

Podobně se chová (ve výchozím nastavení) i český MS Outlook 2007.
I zde lze ale přepnout na pravidlo číslování týdnů přes
Nástroje/Možnosti/Možnosti kalendáře/První týden roku: "První týden se 4 dny"

Jak nalepit desetinná čísla z SQL Server Management Studia do Excelu?

honzas — Tue, 12 Jan 2010 14:12:00 GMT

Pokud pracujete na počítači s českým regional settings a potřebujete výsledek SQL dotazu z gridu v SQL Server Management Studiu (SSMS) přenést přes clipboard do Excelu, narazíte na to, že SSMS používá u desetinných čísel (datového typu Decimal) natvrdo desetinnou tečku (kdežto Excel vyžaduje desetinnou čárku). Takže se čísla do Excelu přenseou jako text.

Microsot to na svém fóru uznal jako bug a v tomtéž threadu lze najít i workaround - stačí přetypovat čísla na Float a SSMS už použije desetinnou čárku.

Ukončení ASPX stránky pomocí Response.End není ideální

honzas — Fri, 20 Nov 2009 12:36:00 GMT

Možná objevuji Ameriku, ale přinejmenším vývojářům v Rebexu doporučuji tento článek přečíst a začít se jím řídit.

Response.End jsem dlouho nepotřeboval používat (kromě ukončování stránek při ladění) a setkávám se s ním teprve v poslední době, kdy jsme si navykli exportovat data z ASPX stránek dle následujícího scénáře:
(scénář je převzat přímo z jendoho dema k DevExpress PivotGridu)

MemoryStream vystup = ZiskejVystupniData(); Response.Clear(); //...nastavení Response HTTP headeru... Response.BinaryWrite(vystup.GetBuffer); Response.End();

Pokud na dané stránce explicitně odchytáváte výjimky, zjistíte, že hází ThreadAbortException
(pokud ale výjimku neodchytáváte, stránka nespadne a v vše funguje bez viditelných problémů).

Článek v MSDN bázi znalostí doporučuje namísto Response.End použít
HttpContext.Current.ApplicationInstance.CompleteRequest.
To obvykle zafunguje, dosud s tím nemám žádné negativní zkušenosti a doporučuji tento způsob preferovat.

Interní poznámka pro vývojáře v Rebexu:
Ukončování stránek pomocí HttpContext.Current.ApplicationInstance.CompleteRequest bohužel nezafunguje v starých projektech, kde se používá UcPage.
V takových situacích doporučuji odchytávat při volání Response.Endu výjimku ThreadAbortException a zahazovat ji.

Jak přinutit .NET aplikaci běžet v 32bit režimu

honzas — Thu, 29 Oct 2009 11:28:00 GMT

Občas se stane, že aplikace v .NETu referencuje jinou .DLL, která pracuje jen v 32bit režimu.
Příkladem je např. MS Jet Engine pro práci s Access databází či SqlServerCe.dll pro přístup do SQL Server Compact databází.

Vše funguje dobře, dokud aplikaci nespustíte na počítači s 64bitovým OS. Pak začne aplikace padat, typicky na "BadFormatException".
Visual Studio totiž defaultně kompliluje aplikace tak, že platformu (32bit nebo 64bit) si volí při spuštění adaptivně podle toho, co je na daném počítači dostupné.

Řešení jsou různá podle dané situace:

Pokud máte přístup ke zdrojákům aplikace,
pak stačí ve vlastnostech projektu na kartě Build přepnout přepínač Plaform target z Any CPU na x86.
POZN: tento přepínač není dostupný u Compact Framework projektů, protože tam se nějakých 64bitů ani neočekává.
Pokud není výsledná assembly podepsaná,
pak můžete cílovou platformu změnit pomocí utility Corflags.exe
Např. corflags.exe application.exe /32BIT+
Je ověřeno, že toto nastavení funguje i na aplikace, zkompilované pro Compact Framework (výsledné .exe pak běží i na stolních i na kapesních Windows)

Pro situaci, kdy nemáte přístup ke zdrojákům a assembly je podepsaná, řešení neznám.

Log4net metoda InfoFormat() se chová jinak, než String.Format()

honzas — Wed, 07 Oct 2009 10:07:00 GMT

Odlišnost jsem potkal při zápisu data a času do logu log4netu:
Narozdíl od standardní metody String.Format formátuje metoda InfoFormat datum dle anglického formátu bez ohledu na CurrentCulture.

Příklad:

_log.Info(string.Format("{0}", DateTime.Now));

vraci 7.10.2009 12:04:49

_log.InfoFormat("{0}", DateTime.Now);

vraci 10/07/2009 12:04:49

Nevím, zda je to bug nebo feauture, ale příjemné mi to není.