Undvik public const i libraries

Dagens läxa: använd public static readonly istället för public const.

I korthet: det är oftast bättre med run-time class constants (konstanta klassvariabler) än compile time constants (inkompilerade konstanter), eftersom de senare kompileras som fasta värden in i assemblies.

Om du använder inkompilerade konstanter i ett library, och har ett annat assembly som är beroenda av ditt library, så kommer även detta andra assembly att kompilera in dina konstanta värden. Effekten blir att alla assemblies som refererar till ditt library måste kompileras om igen när du ändrar på en konstants värde. Använder du istället konstanta klassvariabler (public static readonly) slipper du denna effekt eftersom konstanternas värden sätts i run-time istället för vid kompilering. Sammanfattningsvis, om du vill ha flexibilitet för konstanter som kan komma att ändras så är det detta som gäller:

public static readonly type identifier

Enumerationer då? Ja, enum resulterar också i inkomplilerade konstanter och lider följaktligen av samma fenomen. Även här måste du alltså vara försiktig om det finns andra assemblies som är beroende av din kod. Microsoft formulerar det så här:

Assigning additional values [to] new versions of enums, or changing the values of the enum members in a new version, can cause problems for dependant source code. It is often the case that enum values are used in switch statements, and if additional elements have been added to the enum type, the test for default values can return true unexpectedly.

If other developers will be using your code, it is important to provide guidelines on how their code should react if new elements are added to any enum types. [enum (C# Reference)]

Nåja, på det stora hela är väl det här inget stort problem; enums brukar ju vara hållbara över tiden och med lite versionshantering av dina assemblies så fixar det sig även med andra inkomplierade konstanter.

Mer detaljer och resonemang här: Constant Comprehension

Technorati tags: .net, development

Implementing the Singleton Pattern in C#

Bra artikel om designmönstret Singleton, med flera alternativa implementationer och resonemang om enkelhet mot prestanda: Implementing the Singleton Pattern in C#.

Technorati tags: .net, development, designmönster

Search and replace med MSBuild och Web Deployment Project

Med hjälp av Web Deployment Project (WDP) och MSBuild Community Tasks kan man komma runt buggen/problemet med themes i uppdateringsbara förkomplilerade ASP.Net-applikationer. Gör så här:

1. Sätt upp ett nytt WDP och öppna projektfilen.
   
   
2. Se till att det alltid skapas en temporär katalog för källfilerna genom att lägga utöka elementet PropertyGroup med:
   
   

   <EnableCopyBeforeBuild>true</EnableCopyBeforeBuild>

   
   
3. Uppdatera BeforeBuild target genom att lägga till en task som tar bort themes från <pages>-elementet:
   
   

   <Target Name="BeforeBuild">

     <FileUpdate

       Files="$(CopyBeforeBuildTargetPath)\web.config"

       Regex="(\u003Cpages.*)(theme=\u0022.*?\u0022)"

       ReplacementText="$1" />

   </Target>

Resultatet blir att aspnet_compiler kör mot en web.config utan themes, vilket ger att vi slipper oönskade modifieringar av aspx-filen, som jag beskrev i förra artikeln. Voilà.

Upprepa vid behov med styleSheetTheme.

Technorati tags: asp.net, development, msbuild, web deployment project

MSBuild Community Tasks

Tycker du att MSBuilds vanliga Tasks är för få och lite för klena? Behöver du trimma build-processen och göra saker som till exempel:

• Hantera versionsnummer
• Regex search and replace i filer
• Ladda upp filer till FTP
• Exekvera script inline i en task
• Kontrollera windows services
• Exekvera SQL
• Läsa, skriva eller transformera xml
• Skapa och kontrollera Application Pools

Ta då en en titt på alla nya fina MSBuild Tasks från MSBuild Community Tasks Project!

Och eftersom det är riktiga MSBuild Tasks så går de följaktligen att använda när du bygger med Visual Studio 2005 Web Deployment Project.

Ladda hem senaste builden från MSBuild Community Tasks Project, uppdatera din WDP projektfil och lägg till en referens till target-filen:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>

Sen är du good to go. VS Intellisense hjälper dig på traven, åtminstone med syntaxen. Dokumentationen kan du ladda hem i det större paketet som även innehåller källkod.

Technorati tags: development, msbuild, .net

Theme settings i web.config i kombination med förkompilerad ASP.Net

En lustig detalj med ASP.Net 2.0 och teman: om du förkompilerar en website så hårdlöds temanamnet från web.configs <pages theme="mytheme"/>, vilket bland annat har uppmärksammats av K. Scott Allen: Caveat With ASP.NET Precompilation and web.config Settings.

Det är inte direkt det beteende man förväntar sig. Hela poängen med web.config är väl att man lätt ska kunna konfigurera sin applikation efter deployment?

Vad mer är, om du publicerar en webapplikation i Visual Studio 2005 och väljer "Allow this precompiled site to be updatable" så förväntar du dig att temainställningen i web.config ska fungera trots förkompileringen, eller hur? Det antyder även Scott i sin artikel. Men icke! Inte heller här funkar det som man förväntar sig. Trots att alla aspx-filer går att ändra och kompileras dynamiskt så slår inte ändringar av temainställningen i web.config igenom i webbapplikationen.

Och här kommer hela poängen med det här inlägget: Om du publicerar en uppdateringsbar webbapplikation och har ställt in temat i web.config, så lägger aspnet_compiler till ett theme-attribut i @Page-direktivet på varje aspx-sida.

Eftersom lokala inställningar i en sida gör före inställningar i web.config så blir temat i praktiken hårdlött i hela applikationen. Lösningen är rimligt enkel: ta bort eller kommentera bort temainställningen ur web.config under publicering/förkompilering och lägg till den igen efteråt.

Alltså, var uppmärksam på hur teman fungerar, ta inget för givet (som vanligt).

Trevlig sommarvärme för övrigt.

Technorati tags: asp.net, development

Applikationsnamn (assembly name, process name)

När man slagit upp samma sak två gånger är det dags att skriva ner det så att man slipper leta igen...

Ibland behöver man ge snygg och/eller läsbar feedback, till exempel när man skriver till eventloggen. Och istället för att hårdlöda in mina applikationsnamn i koden föredrar jag att plocka fram dem programmatiskt.

Så här plockar du fram namnet på aktuellt assembly:

using System.Reflection;

string an = Assembly.GetExecutingAssembly().GetName().Name;

Och så här får man namnet på den process som exekverar koden, två alternativ:

using System.Diagnostics;

string pn1 = Process.GetCurrentProcess().MainModule.ModuleName;

string pn2 = Process.GetCurrentProcess().ProcessName;

Technorati tags: development, .net

Ghosting/unghosting i SharePoint 2003

Är du bekant med ghosting/unghosting i Sharepoint? Kortfattat kan man säga att det är en oönskad bi-effekt som uppstår när man redigerar en webbdelssida med Frontpage (eller, gud förbjude, via webdav/webclient). Den ändrade sidan sparas i databasen istället för filsystemet på front end-servern, vilket resulterar i mer databas-trafik och sämre prestanda.

Hur allvarligt det här är beror givetvis på aktuell applikation, antal användare och belastning på servern. Jag brukar sällan bry mig eftersom enkelheten med Frontpage oftast uppväger eventuella prestandaförluster.

I vissa fall behöver man dock kontrollera unghosting och konvertera sidor tillbaks till sitt ursprungliga ghostade läge. Här är ett par verktyg som hjälper dig med det:

• ReGhost.NET
• Ghosthunter (Web Part Toolkit)

Technorati tags: sharepoint

SharePointKicks.com

Ny (ännu en!) community site om SharePoint: SharePointKicks.com.

Just den här bygger på att alla hjälps åt att betygsätta innehållet (som digg.com) och förhoppningsvis hamnar det som är absolut hetast för tillfället allra överst på topplistan.

Om det funkar så kan det bli en bra källa till info om SharePoint. Om det inte funkar så... ja, då glömmer vi den illa kvickt. Den som lever får se.

Technorati tags: sharepoint

Web Part Packages à la SharePoint 2007

I WSS 3.0 (och följaktligen även MOSS 2007) kan man sjösätta siter, funktioner och webparts med hjälp av ett solution package, vilket egentligen bara är en CAB-fil med manifest och resursfiler precis som tidigare men med större möjligheter. En Solution kan omfatta en eller flera:

• Site definitions (en konfiguration med navigation, listor, sidor och features)
• Feature definitions (moduler, listor, funktioner som kan aktiveras/deaktiveras för olika scope)
• Web part files (.dwp)
• Template pages (.aspx, även sidor för _layouts)
• Resursfiler (.resx)
• Assemblies (för bin och GAC)
• ... mm.

Själva installationen är sedan en tvåstegsprocess: först lägger man till sin solution till SharePoint Solution Store, med hjälp av stsadm -o addsolution, för att därefter placera den på front end-servern med hjälp av stsadm -o deploysolution. (Med reservation för fel, uppgifterna här har jag inte testat ännu.)

SharePoint Solutions har en artikel som visar hur man gör med webparts och solution packages: Deploying Web Parts with Solution Packages in WSS v3/MOSS 2007.

För den som tycker att makecab.exe är omständlig så tipsar jag om att du kan göra ett CAB Project i Visual Studio, vilket ger alltså ger en CAB-fil som output. Projektmallen hittas under Other Project Types/Setup and Deployment. Jag är dock osäker om denna metod ger tillräcklig kontroll över den resulterande CAB-filen, men det kan vara värt att undersöka.

Technorati tags: sharepoint, webparts

Så sätter du upp Forms Authentication för SharePoint 2007 beta 2

Här finns en instruktion hur man går tillväga för att sätta upp formulärbaserad inloggning (Forms Authentication) i beta 2: SharePoint 2007 Forms Authentication. Förmodligen användbart inom snar framtid...

Technorati tags: sharepoint

CopySourceAsHtml (CSAH)

Ett par veckor med fokus på annat, but here goes again. Jag återupptäckte en gammal utility som är praktisk när du ska kopiera formaterad källkod från Visual Studio till HTML. Klockrent verktyg och given (åter)installation: CopySourceAsHtml (CSAH).

Technorati tags: visual studio 2005, utility