See Scott Hanselman's blog for details (no use repeating his post): http://www.hanselman.com/blog/FreePowerShellIDE.aspx

Ik ben nooit zo van de command line geweest, maar Windows Powershell (voorheen bekend als "Monad") is wel heel cool. Om het makkelijker te maken om Powershell scfiprts te maken is het toch wel prettig dat er ook weer een IDE is. Zie deze post van Scott Hanselman.

Het scenario:
Een bestaande applicatie schrijft (Word) bestanden in een image-field in een SQL Server database, en jij moet ze er weer uithalen en naar een browser sturen.

De oplossing:
Je zou zeggen "no problemo", met een DataReader kan ik bytes uit het betreffende veld lezen, en als ik gebruik maak van een DataAdapter+DataSet dan heb ik de hele byte array. Vervolgens gebruik je gewoon Response.BinaryWrite. Dat dacht ik eerst ook, totdat ik het deed en Word niet met het bestand overweg bleek te kunnen.

In dit saoort gevallen is een HEX viewer onmisbaar. Trek een bestaand document open en kijk hoe die er op byte niveau uitziet, en doe hetzelfde met het foute bestand. In mijn geval viel op dat we dezelfde karakters erin stonden, maar in het foute bestand staat een extra byte tussen alle karakters. Het foute bestand maakt dus kennelijk gebruik van 16-bits karakters, vermoedelijk UTF-16 (Unicode). Om dat te verhelpen kun je gebruik maken van de System.Text.Encoding class:

Encoding.Convert(Encoding sourceEncoding, Encoding destinationEncoding, byte[] sourceByteArray);

Mijn eerste gok was UTF-16 naar UTF-8, maar dat bleek niet goed te zijn. Ook de andere in .NET bekende encodings (UTF-7, ASCII) leverden niets op. Terug naar de Windows code pages dus... Mijn eerste gok was meteen goed: windows-1252, waardoor de code hieronder het gewenste resultaat leverde (GetDocument is een functie die en byte array teruggeeft van het bestand in de database):

Encoding targetEncoding = Encoding.GetEncoding(1252);
Response.Clear();
Response.ContentType = "application/ms-word";
Response.AddHeader("Content-Disposition", "attachment;filename=bestand.doc");
Response.BinaryWrite(Encoding.Convert(Encoding.Unicode, targetEncoding, DocDataAccess.GetDocument(documentId)));

You can watch the top sessions (including Gates') on It's Showtime, as is the case with sessions from TechEd and other events.

Je kunt de beste sessies (inclusief die van Ome Bill) nu bekijken op It's Showtime, evenals sessies van o.a. TechEd.

I think Microsoft has made a smart move in renaming WinFX (including .NET 2.0) to .NET 3.0 (see blog post by Soma Somasegar). First of all there was a lot confusion about what .NET and WinFX are, and secondly WinFX is often confused with WinFS (the new file system). Us developers can all do with a little less confusion finding out way through development technologies.

Microsoft heeft een wijs besluit genomen door de term WinFX te laten vallen ten faveure van .NET Framework 3.0. WinFX leverde ten eerste naamsverwarring op ten opzicht van WinFS en ten tweede was het niet voor iedereen duidelijk wat nu het verschil was tussen het .NET Framework en WinFX (wat er eigenlijk ook niet echt is). Overigens schept het versienummer 3.0 wel weer een beetje verwarring, omdat er hele delen zijn die niet aangepast worden.

Dit is trouwens ook heugelijk nieuws voor de .NET gebruikersgroep dotNED, omdat hiermee een naamsverandering in de toekomst niet nodig is. 

Om een of andere reden denken kopstukken uit het Nederlandse bedrijfsleven dat wij als zorgconsument marktwerking in de zorg willen. Nou, ik niet! Ik wil dat als ik het dichtsbijzijnde ziekenhuis binnenloop, ik zo snel en zo goed mogelijk geholpen wordt. Zorg is geen mobieltje waar ik desnoods kilometers voor omrij om een betere prijs-kwaliteitsverhouding te krijgen. Door keuze en marktwerking loop ik het risico dat het dichtsbijzijnde ziekenhuis straks 10 km verderweg is, omdat de goede ziekenhuizen meer geld krijgen. Dat kan het verschil zijn tussen leven en dood. We moeten niet zorgen dat sommige ziekenhuizen beter worden dan anderen, we moeten zorgen dat alle ziekenhuizen beter worden.

Eigenlijk zouden we een voorbeeld moeten nemen aan de Scandinavische landen die de top-5 van beste zorg in Europa domineren. Daar heeft de overheid het voor het zeggen in de zorg, en zo zou het ook moeten zijn met dit soort onmisbare voorzieningen. Dat zijn wat mij betreft zorg, onderwijs, politie en brandweer, en mogelijk ook gas, elektra en water. Ik moet er niet aan denken dat er in Nederland mensen zonder energie komen te zitten omdat Engeland bereid is een hogere prijs te betalen. Bovendien zou er veel meer geinvesteerd moeten worden in duurzame energie, iets wat blijkbaar ook niet kan zonder de overheid.

I recently downloaded the Windows Workflow Hands On Labs for WF beta 2 and found the samples to be less than perfect. For instance the state management example (Lab 04) doesn't even build because there are some workflow fields set to private instead of public. Remedy that and the application will run. Not that it'll help... it crashes almost immediately. Looking at the code I can see that it is not beta 1, but I assume that it is pre-beta 2. This is a big disappointment because I'd like people within my company to do the labs to get to know WF. I hope the WF team tests and debugs the current hands on labs and puts out a new download that works well with beta 2.

Vandaag heb ik een presentatie gegeven over Windows Workflow Foundation (WF) aan onze .NET thema groep binnen The Vision Web. Gezien mijn laatste ervaring met WF nog met Beta 1 was, en ik keurig een Beta 2 omgeving had opgezet in een Virtual PC, was het even schrikken toen ik aan m'n demo's ging werken. De API is op sommige plaatsen behoorlijk aangepast, die me vooral even teruggooiden toen ik met State Machine workflow aan de gang ging. Ik dacht gered te zijn toen ik op windowsworkflow.net Beta 2 demo's tegen kwam en later de WF Hands On Labs Beta 2. Sommige voorbeelden uit de Hands On Labs werken echter niet, sterker nog ze builden niet eens! Ik vermoed dat dit nog pre-beta 2 voorbeelden zijn die nog net niet helemaal bijgewerk zijn.