Jeg sad idag og boksede med et problem i Visual Studio, hvor jeg ikke kunne få intellisence til at fungere. Dette til trods for, at jeg godt kunne complie projektet og køre det i IIS Express.

Der var røde bølgestreger under et namespace i using-sektionen og en type kunne ikke findes. Da projektet kunne compile, tænkte jeg det måtte have noget med udviklingsmiljøet at gøre.

Jeg havde lavet en cleanup og forsøgt at køre "rebuild" på hele min solution, men lige lidt hjalp det. 

Jeg søgte på problemet og fandt dette link: https://stackoverflow.com/questions/21471887/visual-studio-2013-intellisense-stops-working-for-asp-net-mvc5-controllers/23983883#23983883

Løsningen var, i mit tilfælde, helt enkelt, at lukke VS 2013 og slette filen <projektnavnet>.v12.suo og starte VS 2013 op igen.

Jeg fik lige et spørgsmål fra en ven, som omhandlede LinkedIn's valg af billede fra en side når der henvises til den fra LinkedIn. Det fik mig så til at lure lidt på Open Graph definitionen (via et link fra en anden ven :-)).

Dette er sådan facebook gør det og givetvis også LinkedIn m.fl.

Kort sagt kan man smide et antal meta-elementer ind i head-sektionen af siden, som angiver hvad der skal tilbydes overfor det sociale medie. Dette kunne f.eks. være 

<meta property="og:image" content="http://example.com/rock.jpg" />
<meta property="og:title" content="Titel på siden" />
<meta property="og:description" content="Beskrivende tekst" />

for at angive hvilket billede man ønsker skal kunne benyttes, samt hvilken titel og beskrivelse der skal følge linket.

Der findes et hav af muligheder for at styre, hvad der skal bruges ifht. de sociale medier og man kan få smag for sagerne ved at kigge på denne siden med The Open Graph Protocol.

Man kan evt. teste på facebook med deres værktøjer (det kræver dog, at man logger på udviklersitet, hvilket ikke burde give nogen problemer for nogen)... 

Jeg er for alvor begyndt at bevæge mig ind i .NET-udvikling og er i den forbindelse igang med at lære en masse nye begreber og metoder, som, for mange metoders vedkommende, ikke har givet så meget mening at arbejde ud fra i et ASP Classic miljø (mest fordi miljøet ikke understøtter værktøjerne til at gøre tingene på den måde).

Jeg tænker på områder som

• SoC (Separation of Concern)
• DI (Dependency Injection)
• DRY (Don't Repeat Yourself)
• Automatiserede tests

m.fl.

Jeg er klar over at man godt kan udøve ovenstående praksiser i ASP Classic (og jeg har da i nogen grad forsøgt dette gennem tiden), men da måden at inkludere kode på er yderst kluntet i mere komplekse scenarier og muligheden for at benytte objektorientering er begrænset, kræver det i bedste fald en yderst disciplineret udvikler at gennemføre dette. Desuden er muligheden for at isolere koden fra IIS begrænsede i ASP og derfor er unittests af kode som benytter session, response, request osv. besværlige i bedste fald.

Begreberne og metoderne er noget lettere at arbejde med i .NET, som i høj grad understøtter disse. Specielt når man arbejder med ASP.NET MVC.

En af de metoder jeg er blevet glad for er DI. DI tvinger mig til at tænke på tingene i mindre og mere afgrænsede opgaver for at få tingene til at hænge ordentlig sammen. DI øger også testbarheden af koden, hvilket understøtter et andet af ovenstående punkter.

DI kan gøres manuelt, men det kan hurtigt blive træls at skulle instantiere objekter alle de steder hvor man skal injicere funktionalitet, så derfor har jeg været på jagt efter et DI-framework, som kunne hjælpe med dette.

Jeg har fundet Ninject. Det eneste DI-framework jeg har prøvet, men jeg fornemmer det skiller sig ud fra mange andre DI-frameworks i.o.m. det ikke konfigureres i en XML-fil og dermed fjerner evt. fejl som følge at tastefejl i den tekstuelle XML. Det er i stedet konfigureret i kode og dermed bliver bindinger testet på compiletidspunktet, hvilket jo giver en tidligere mulighed for at fange evt. fejl. Dermed ikke sagt at det fjerner kørselsfejl ifm. instantiering, men det er en fejlkilde mindre ifht. konfiguration via XML.

Der findes et hav af extensions til Ninject, herunder til webforms, mvc3 og azure. Jeg har ikke selv arbejdet i meget andet end MVC 3 med ninject (ud over et lille testprojekt til webforms), så jeg har ikke den store erfaring med hvordan det fungerer i andre sammenhænge, men mon ikke det mest er et spørgsmål om opsætning. Resten kører nok ens, uanset projektets form, når først DI-frameworket er initialiseret.

Du kan tjekke ninject ud her: www.ninject.com