Jag har precis läst klart boken Pro ASP.NET MVC av Steven Sanderson. Resultat: jag är gravt peppad att sätta igång med ASP.NET MVC! Jag gillade verkligen den här boken; Sanderson skriver strukturerat och koncist, med en blandning av djupdykningar i tekniken och konkreta kodexempel. Ett klart plus är också att han inte är associerad med Microsoft – flera gånger understryker han att hans exempel inte handlar om ”demoware” utformade att få ramverket att glänsa utan skulle kunna fungera i en verklig situation. Boken går igenom många aspekter av webbutveckling med snygg mjukvarudesign som röd tråd och jag upplevde att den förklarar principerna bakom MVC-mönstret på ett mycket grundligare sätt (och lämnar färre frågetecken) än exempelvis Professional ASP.NET MVC 1.0 (av bland andra Scott Guthrie) som jag läst tidigare.

Om du är det minsta nyfiken på ASP.NET MVC så tycker jag absolut att du ska låna eller köpa den här boken. När jag skaffade den kostade den knappt 300 kr och det var den utan tvekan värd.

Ända sedan jag testade Windows 7-betan har jag haft för avsikt att installera slutversionen på min stationära dator så snart den finns tillgänglig, för att äntligen ersätta sorgebarnet Windows XP x64. Ännu är det några veckor kvar till officiell release, men jag upptäckte att jag helt missat att RTM-versionen funnits uppe på MSDN (och TechNet) sedan början av augusti…alltså fanns det ingen anledning att vänta längre!

Läs vidare »

Jag har under de senaste åren vid ett flertal tillfällen stött på WebBrowser-kontrollen, som är en .NET wrapper-klass till en underliggande ActiveX-kontroll motsvarande en Internet Explorer-instans. Kontrollen gör det enkelt att lägga in ett webbläsarfönster i sina .NET-baserade Windowsprogram, och även om den är lite bänglig att jobba med så har den definitivt sina tillämpningsområden.

Nu senast var det hos en kund som jag satt och fipplade med WebBrowser. Jag ville att popup-fönster skulle öppnas i en ny WebBrowser-kontroll istället för i ett vanligt Internet Explorer-fönster (vilket är standardbeteendet), och det gick att åstadkomma med lite pill. När användaren öppnat en popup och sedan stängde den så slängdes WebBrowser-instansen bort, med allt vad det innebär av Dispose():ande. Det jag insåg ganska snabbt var att det minne som allokerades vid skapandet av popup-webbläsaren inte frigjordes när den stängdes. En minnesläcka alltså. Detta var något som sett i tidigare projekt, men då handlade det mest om det minne som kontrollen läcker varje gång en ny sida laddas, vilket sker i ett mycket långsammare tempo. Jag hade aldrig tidigare kommit på varför minnesläckorna uppstått eller hur jag skulle komma till rätta med dem. Det har heller inte varit något affärskritiskt i de tidigare fallen, men för den här aktuella kunden var det just det.

Efter lite Googlande kunde jag konstatera att minnesläckorna i WebBrowser-kontrollen är kända av Microsoft, och att det även finns ”hotfixes” för dem (som jag tror ska vara inkluderade i diverse service packs för olika versioner av Windows). Jag provade att installera en sådan hotfix och kunde inte se någon skillnad överhuvudtaget.

Några timmar senare hittade jag däremot ett mycket intressant API-anrop som jag faktiskt tror löser min kunds problem, nämligen SetProcessWorkingSetSize i assemblyn kernel32.dll. Metoden används för att ställa in övre och undre gränser för det reserverade arbetsminnet för en given process, men om man anropar den med -1 som parametrar för gränserna så frigörs så mycket arbetsminne som möjligt. Så här kan det se ut i ett program skrivet med C#:

// Importera metoder från kernel32.dll, någonstans i klassdefinitionen...
[DllImport("KERNEL32.DLL", EntryPoint = "SetProcessWorkingSetSize", SetLastError = true, CallingConvention = CallingConvention.StdCall)]
internal static extern bool SetProcessWorkingSetSize(IntPtr pProcess, int dwMinimumWorkingSetSize, int dwMaximumWorkingSetSize);

[DllImport("KERNEL32.DLL", EntryPoint = "GetCurrentProcess", SetLastError = true, CallingConvention = CallingConvention.StdCall)]
internal static extern IntPtr GetCurrentProcess();

// ...och frigör arbetsminne där det passar.
IntPtr pHandle = GetCurrentProcess();
SetProcessWorkingSetSize(pHandle, -1, -1);

Så var det med den saken. Den ursprungliga forumtråden där jag läste om detta hittar du här, och Microsofts dokumentation av de aktuella metoderna i kernel32.dll finns här. Hoppas det hjälper någon.

I ett tidigare inlägg skrev jag om hur jag med ett kommando lyckades få min jobbdator med Vista att kommunicera med det trådlösa nätverket på min arbetsplats. Jag har dock hela tiden haft problem med att samma dator inte har kunnat få någon IP-adress från routern i nätverket hemma, varken via kabel eller WLAN. Nu har jag äntligen hittat problemet, genom gammal hederlig ad-hoc trial and error…

Routern som jag har är en Linksys WRT54GL med programvaran DD-WRT installerad. Jag är på det hela taget mycket nöjd med den – den är den tredje jag testat sedan jag flyttade till Stockholm och den är helt överlägsen de tidigare när det gäller stabilitet och funktionalitet. Men, som det visade sig, den var i sitt defaultutförande (eller möjligen i DD-WRT:s defaultutförande) inte helt Vista-kompatibel.

Problemet har alltså varit att Vista har kunnat koppla upp sig mot routern, men aldrig fått någon IP-adress. Under nätverksinställningarna har det stått att nätverket är ”Local only” och sådana saker, vilket förstås inte stämmer.

Lösningen: I DD-WRT, gå in under Setup > Basic Setup > Network Address Server Settings (DHCP). Kryssa ur ”Use DNSMasq for DHCP”. Klicka på Apply Settings. Klart! Vista kommer nu kunna få en IP-adress precis som alla de andra barnen.

Då kan man förstås lite nyfiket undra vad DNSMasq är för något. Jag googlade det och fick reda på att det är en ”lättvikts- och lättkonfigurerad DNS-forwarder och DHCP-server designad för små nätverk”. Jag har ingen aning om varför den inte funkade med Vista i kombination med min routerkonfiguration eller hur min router väljer att lösa DHCP- och DNS-frågan när jag stängt av denna funktion, och jag orkar inte bry mig heller riktigt. Det funkar – det är allt som spelar roll.

Okej, jag hade just skrivit nästan ett helt blogginlägg, kanske någon A4-sida, när Live Writer plötsligt slängde upp en dialogruta och sa ”Du har ändringar som inte sparats. Vill du verkligen avsluta?”. Jag hann tänka ”whaa?” innan rutan försvann och datorn startades om. Behöver jag berätta huruvida det jag skrivit fanns kvar när jag kom tillbaka in i programmet?

Tydligen hade Windows Update körts i bakgrunden, och tydligen fanns det information om att datorn skulle startas om i en minimerad dialogruta som jag, blind och döv som jag är, inte lade märke till när jag koncentrerat satt och skrev. Jag måste ha gjort misstaget att rikta min uppmärksamhet mot mitt arbete istället för mot statusraden.

Undrar hur de tänkte när de kodade in den funktionen, förresten. Kanske något i stil med ”Windows vet ju bäst när datorn akut måste startas om (jag menar, shit, den kanske har uppdaterat Outlook eller något), men vi vill samtidigt inte störa användaren i dennes arbete…argh, dessa svåra avvägningar…låt oss tillämpa en kompromiss…”?

Det förlorade blogginlägget (som jag för övrigt sett fram emot att skriva hela dagen) får jag väl alstra någon annan dag, för nu fick jag en sjuk brist på inspiration.

Uppdatering: Av nyfikenhet kollade jag vad det var som Windows installerat och behövde starta om datorn för. ”Säkerhetsuppdatering för Windows Live Writer”. Ironin flödar.