Archive for the ‘.NET’ Category
Kalenderwochen-Nummerierung in .NET
Um die Realität auf der ganzen Welt einigermaßen widergeben zu können, ist das .NET-Framework sehr flexibel, wenn es darum geht, die Nummer einer Kalenderwoche zu ermitteln.
Der Methode CultureInfo.CurrentCulture.Calendar.GetWeekOfYear kann man sagen, welches der erste Wochentag ist und welche Regel anzuwenden ist, um die KW eines DateTime-Objekts zu identifizieren. Ich habe mich ab und zu gefragt, welche Einstellungen ich dabei für die beiden genannten Regeln treffen soll.
Wie gut, dass es für alles Normen gibt. In DIN 1355 ist nämlich unter anderem festgehalten, wie das für deutsche Kalender auszusehen hat:
- Beginn der Woche ist Montag (was nebenbei den Mittwoch von seiner Rolle als Mitte der Woche enthebt)
- KW 1 ist die Woche, zu der vier oder mehr Tage der ersten sieben Januartage zählen
Auf .NET angewendet heißt das:
CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(myDate, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday)
C#: System.DayOfWeek output localized Weekday name
I have a plain DayOfWeek value and want to output the corresponding localized weekday name. Since it is an enum, there is no localization, says Microsoft. This is by design and will not be implemented in any way. I shall use DateTime’s .ToString(“dddd”). Alright, but I have no DateTime object from which I get the DayOfWeek. No problem. Here’s a workaround:
private string GetLocalizedWeekdayName(DayOfWeek d)
{
DateTime dt = DateTime.Today;
while (dt.DayOfWeek != d)
{
dt = dt.AddDays(1);
}
return dt.ToString("dddd");
}
ClickOnce-Zertifikat erzeugen
Heute stand ich vor dem Problem, dass ich eine neue Version einer ClickOnce-Anwendung erstellen wurde. Visual Studio hat mich mit einer Fehlermeldung konfrontiert, die darauf hingedeutet hat, dass ich die Anwendung nicht Signieren kann. Ein Blick in die Einstellungen brachte die Information, dass das Zertifikat, welches VS.NET (ziemlich genau vor einem Jahr) für mich angelegt hat, nicht mehr gültig ist.
Klar, neues Zertifikat erstellen, einbinden, Installer bauen, verteilen – so dachte ich. Dummerweise nimmt ClickOnce es sehr ernst, von wem die Anwendung ursprünglich signiert war. In meinem Fall eben von jemandem, der kein gültiges Zertifikat mehr hat. Also wird kein Weg daran vorbei führen, die Anwendung bei den Benutzern zu deinstallieren und mit dem neuen Zertifikat wieder zu installieren. Hätte ich daran mal vor einem Jahr gedacht …
Naja, dass ich nicht mehr daran denken muss: So habe ich mit openssl ein ca. 20 Jahre gültiges Zertifikat erstellt:
openssl genrsa 1024 > host.key
openssl req -new -x509 -nodes -sha1 -days 7200 -key host.key > host.cert
type host.cert > host.pem
type host.key >> host.pem
openssl pkcs12 -export -out host.pfx -in host.pem -name "beschreibender name"
Der HttpHandler und die Session [update]
Heute habe ich bemerkt, dass ich in einem IHttpHandler (ashx) an den HttpContext komme, allerdings die Session darin immer null ist.
Das scheint in HttpHandler-Kreisen so üblich, aber es gibt eine Abhilfe:
Die Klasse muss das Interface IRequiresSessionState implementieren.
Das ist garnicht schwierig, da die Implementierung keinen weiteren Code erfordert. Einfach die Klasse folgendermaßen definieren:
public class MyHandler : IHttpHandler, IRequiresSessionState
Nachtrag:
Damit es funktioniert, sollte man noch System.Web.SessionState includen:
using System.Web.SessionState;
GridView: Zahlen formatieren
Ich musste heute in einer GridView Zahlen formatieren, und zwar mit Tausender-Trennzeichen. Eigentlich kein Problem, wie bei der guten alten DataGrid als format string {0:###,###} eintragen. Dummerweise hat das nichts gebracht. Die Lösung war denkbar einfach: Man muss für die betreffende Zelle das HTML encoding abschalten.
ClickOnce-Installer in IE6 wird nur XML angezeigt
Beim Aufrufen eines .NET 2.0 ClickOnce-Installers wird auf einem Rechner mit IE6 nur der Inhalt der .application-Datei vom Server angezeigt. Auf dem Rechner ist Windows XP und .NET 2.0 installiert, also eigentlich müsste das klappen.
Wenn jedoch auf dem Server kein .NET2.0 installiert ist oder dieser gar nicht unter Windows läuft, dann hilft es, den Mime-Type für .application-Dateien dort einzutragen.
In meinem Fall per .htaccess:
AddType application/x-ms-application application
Und schon ging das.
Mit IE7 hat’s übrigens gleich funktioniert. Der scheint von sich aus zu wissen, wie man mit .application-Dateien umgeht.
VS.NET 2005 Debugger: “Step Into” weg
Heute hat mir die Step Into – Funktion im Debugger so sehr gefehlt, dass ich danach gegoogelt habe und siehe da, es gibt eine Lösung. Man lösche einfach sein Profil in VS.NET 2005, warum auch immer das nötig ist …
1) Click the Tools->Import and Export Settings menu item
2) Choose Reset all Settings
3) Don’t save your settings
4) Pick a new profile
Quelle:
http://aspadvice.com/blogs/plitwin/archive/2005/11/12/13767.aspx
Für die Suche: Visual Studio
Fenster komplett verstecken
Ich musste ein Fenster verstecken, sodass es nicht im Alt-Tab-Menü zu sehen war.
Die Lösung war folgende:
- Form.ShowInTaskbar auf false setzen
- Form.FormBorderStyle auf FixedToolWindow oder SizableToolWindow setzen
Quelle:
http://episteme.arstechnica.com/eve/ubb.x/a/tpc/f/6330927813/m/190001652731/r/953007043731
Icons für Vista erstellen
Heute habe ich mich einmal mehr über die Unfähigkeit von Visual Studio 2005 aufgeregt, keine Icons mit Alphakanal zu erstellen. Entweder hat man also bei transparentem Hintergrund ausgefranste Kanten oder macht man den Hintergrund nicht transparent. Windows XP/Vista kann jedoch mit stufenweiser Transparenz umgehen, wenn man die richtigen Programme hat.
Heute habe ich ein Tool gefunden, welches das Erstellen von .ico-Dateien sehr einfach macht:
Das Tool heißt IcoFX, ist kostenlos und hier beziehbar:
http://icofx.xhost.ro/
DateTime und ParseExact
Es kommt ja manchmal vor, dass man ein bestimmt formatiertes Datum in ein DateTime-Objekt verwandeln will.
Im aktuellen Fall war es das Format
2007-03-27T18:33:21.123
Dafür gibt es DateTime.ParseExact und so hat das bei mir funktioniert:
DateTime meinDatum = DateTime.ParseExact(meinString, "yyyy-MM-ddTHH:mm:ss.fff", CultureInfo.InvariantCulture);
In einigen Quellen war zu lesen, man müsse Doppelpunkte und andere Zeichen Quoten, das war jedoch nicht nötig. Funktioniert hat es aber erst, nachdem ich CultureInfo.InvariantCulture als zweiten Parameter angegeben habe.