Jeg har lige været lidt eventyrlysten og opgraderet et MVC 4 projekt fra EF5 til EF6. Efter det havde jeg lidt problemer med at få mit site til at køre på serveren (efter web deploy og auto migrations på serveren).

Fint nok, så nedgraderer jeg bare til EF5 igen og så burde den jo være i vinkel... men ak, så let skulle det ikke gå. Flg. fejl opstod når jeg prøvede at publisere:

Cannot insert the value NULL into column 'ContextKey', table 'ScabsContext.dbo.__MigrationHistory'; column does not allow nulls. INSERT fails. The statement has been terminated.

OK, nu er jeg ikke 100 meter mester udi tabelstrukturen på MigrationHistory, så jeg tænte der måtte være en uoverensstemmelse mellem EF-versionerne i de forskellige komponenter i min solution, så jeg sikrede mig, at alle versioner var ens. Lige lidt hjalp det.

Hmm... Google! Kommer op med et Stack Overflow-indlæg, som omhandler dette emne (SO styrer for vildt!).

Det viser sig, at EF6 tilføjer en ny kolonne i MigrationHistory, som hedder (trommehvirvel!) - ContextKey.

Denne ContextKey bliver jo ikke fjernet fra tabellen igen, bare fordi man nedgraderer fra EF6 til EF5, så når en migration køres fra EF5 mod en EF6 MigrationHistory... ja, så får du førnævnte fejl.

Dette kan løses ved at udføre flg. ændringer på MigrationHistory-tabellen:

ALTER TABLE dbo.__MigrationHistory DROP CONSTRAINT [PK_dbo.__MigrationHistory2]

ALTER TABLE dbo.__MigrationHistory DROP COLUMN ContextKey

ALTER TABLE dbo.__MigrationHistory ADD CONSTRAINT [PK_dbo.__MigrationHistory] PRIMARY KEY (MigrationId)

ALTER TABLE dbo.__MigrationHistory ALTER COLUMN MigrationId NVARCHAR(255) NOT NULL

Så skulle den tabel vist være tilbage i EF5-format!
 

Har man brug for at få værdier ud af en funktion kan man naturligvis bruge funktionens returværdi, hvilket er oplagt i de fleste tilfælde. Der kan dog være tilfælde, hvor man har brug for at returnere flere værdier fra en funktion og i disse tilfælde har man et par yderligere muligheder.

out-parametre

Med out-parameteren kan man sende en værdi ud af et funktionskald. Parameteren SKAL tildeles en værdi inde i funktionen, ellers får man en compilefejl. Parameteren er KUN til output, evt. værdi i input vil blive ignoreret. Følgende vil give en compilefejl (fordi p endnu ikke er tildelt en værdi inde i fn, inden den refereres):

void fn(out int p)
{
    return p + 1;
}
var x = 1;
fn(out x);

Samtidig opfattes denne parameter alene som en output-parameter, dvs. den værdi parameteren evt. måtte have i kaldet, kan ikke bruges i funktionen. Følgende vil f.eks. give en kørselsfejl, fordi parameteren p ikke er tildelt en værdi inden den bruges (inde i funktionen):

void fn(out int p)
{
    Console.WriteLine(p);
    p = 2;
}
var x = 10;
fn(out x);

ref-parametre

Med ref-parametre kan man sende værdier ind i en funktion og samtidig give funktionen mulighed for at ændre værdien af den parametere (så den også ændres i den kaldende parts variabel). Dette kunne se således ud:

void fn(ref int p)
{
    p++;
}
var x = 1;
fn(ref x);
// x er nu 2;

Denne måde at bruge ref på, kan være "farlig" og betragtes af mange som dårlig kodestil. Begrundelsen er, at kaldet til fn har en skjult sideeffekt på den kaldende parts kode. Denne sideeffekt er svær at forudse, hvis man ikke lige har adgang til koden i fn og kan se hvad der sker. Selvom man havde adgang til koden, var det ikke nødvendigvis let at gennemskue denne sideeffekt alligevel. Det er derfor ikke tilrådeligt, at benytte ref på denne måde.

Når ref-modifikatoren bruges er det den variabel som står på parameterens plads i kaldet, der ændres (direkte i den hukommelsesplads variablen ligger). Det betyder også, at når der medsendes en referencevariabel (bla. objekter, strenge, arrays), så er det referencen der ændres, dvs. der peges på en anden forkomst af den medsendte type. Dette er fordi referencevariable i sig selv er referencer (navnet havde nok allerede afsløret dette) og det er altså pegepinden der ændres.

Det samme gælder for simple typer, hvor værdien ændres direkte i den hukommelsesposition, hvor variablen er defineret inden kaldet til funktionen.

Hukommelsespositionen kan dels være på "heapen", dels på stakken. Stakken benyttes hvis kaldet sker med en lokal variabel fra en anden funktion.

Jeg har bakset lidt med en fejl, der opstod i forbindelse med opdatering af en LINQ to SQL-entity. Helt konkret drejer det sig om den lidet informative fejl: "Operation is not valid due to the current state of the object", som opstår i forbindelse med at jeg tildeler en værdi til en fremmednøgle i denne entity.

Setup'et

Jeg opererer med optimistisk samtidighed og et afkoblet datasæt, dvs. jeg læser objektet, lukker forbindelsen og skaber en ny forbindelse, når jeg skal opdatere data (et typisk scenarium for websites der involverer en bruger mellem læsning og opdatering). I forbindelse med selve opdateringer indlæser jeg først objektet (og beholder forbindelsen til databasen), opdaterer entity'objektet og opdaterer databasen. Jeg har altså gang i noget med at kopiere data fra entity over i et forretningsobjekt og tilbage igen ifm. opdatering.

Idet min entity læses sætter jeg nogle LoadOptions på forbindelsen, så relevante relaterede rækker fra andre tabeller også indlæses. Dette gøres af performancemæssige hensyn, da en reference til disse relaterede entities ville forårsage en "lazy loading" af data og dermed endnu et opslag i databasen.

Løsningen

Denne "eager loading" af relaterede data giver problemer, hvis jeg forsøger at opdatere fremmednøglen og ikke samtidig sætter det relaterede objekt til den nye entity (som nøglen også refererer til).

Jeg skal altså IKKE preloade relaterede tabeller, hvis jeg blot ønsker at benytte fremmednøglen til opdateringshandlinger.

Alternativt kunne jeg måske klare mig ved at benytte Attach i stedet for at læse entity inden opdatering. I dette scenarium ville der nok ikke ske en "eager load" af relaterede tabeller (jf. LoadOptions). Det har jeg dog ikke eksperimenteret med endnu...

Se også

http://www.faridesign.net/2010/11/linq-to-sql-operation-is-not-valid-due-to-the-current-state-of-the-object/

Jeg har et projekt som kører .NET 4.5 og MVC 5, hvor der også er noget OAuth involveret. I den forbindelse forsøger jeg at lave noget Reflection, men får en fejl som omhandler sikkerhed. Det viser sig at DotNetOpenAuth ikke er compatibel med MVC 5, fordi der er sket en ændring i måden sikkerheden håndteres i MVC 5 ifht. MVC 4. Desværre vedligeholdes DotNetOpenAuth ikke aktivt i øjeblikket, men der er dog lavet en eller anden løsning til problemet... jeg har bare ikke været i stand til at få den til at fungere.

Workaround

I stedet for at gennemløbe alle typer i alle assemblies, nøjes jeg med at gennemløbe dem i den assembly jeg har brug for (hvilket så gør, at jeg undgår projektet med DotNetOpenAuth-dll'erne) og problemet er dermed gemt af vejen.

Der findes som sagt en opdatering til DotNetOpenAuth som er rettet mod MVC 5 og den kan hentes via NuGet:

Install-Package DotNetOpenAuth.Mvc5

Jeg havde for nylig et site der kørte på Umbraco og som kørte enormt langsomt og fungerede egentlig ikke rigtigt. Jeg undrede mig en del over det, for indholdsmæssigt var det ikke et tungt site (kun få sider - mindre end 100), men et site der havde været i drift i en længere periode. Jeg besluttede mig for at finde ud af hvorfor det ikke fungerede. Her er hvad jeg fandt frem til...

Symptomerne

Sitet kørte som nævnt ikke rigtigt. Helt konkret var det enormt langsomt til at indlæse træstrukturen og det var et held, hvis man fik lov til at oprette nye dokumenter.

Det er klart, at man ikke kan forvente hvad som helst af en 10+ år gammel undskyldning for en server, men jeg havde da også andre Umbraco-sites på denne server, som slet ikke havde problemer med at køre, så jeg mente jo nok dette ikke burde være et problem. Også det faktum, at der var tale om et Umbraco v3.0.6 kunne vække en vis bekymring, men igen, så var der også andre sites i denne version, på samme server, som kørte tilfredsstillende.

Opdagelsen

Efter af have kigget lidt rundt i Umbraco-admin, uden dog at kunne finde noget, der virkede himmelråbende tåbeligt konfigureret, bedrog jeg mig ud i stifinderen, for at se om der kunne være noget der. Første stop web.config, men også her så tingene tilforladelige ud, så heller ikke der synes jeg, der var noget at hente.

Efter lidt stikken og justeren, fandt jeg frem til databasefilerne (data og log) for sitet og til min store overraskelse opdagede jeg, at data-filen fyldte 2.3+ Gb! Det var vist ikke nødvendigt for sådan et lille site, så noget måtte være galt, men hvad!?

Undersøgelsen

Gad vide hvordan sådan en Umbraco database er bygget op? En hel masse tabeller præfikset med cms og umbraco og lidt svær at gennemskue, hvis man ikke har arbejdet indgående med sådan en før (hvilket jeg ikke havde), så Google måtte kunne hjælpe...(?)

Først og fremmest måtte jeg have et overblik over hvormeget data der var i hvilke tabeller. Til dette formål fandt jeg flg. SQL-script, som, om en given database, kunne fortælle mig, hvormange rækker der er i hver tabel, hvormeget tabellens indhold fylder i Kb m.m.

SELECT 
    t.NAME AS TableName,
    s.Name AS SchemaName,
    p.rows AS RowCounts,
    SUM(a.total_pages) * 8 AS TotalSpaceKB, 
    SUM(a.used_pages) * 8 AS UsedSpaceKB, 
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM 
    sys.tables t
INNER JOIN      
    sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN 
    sys.partitions p ON i.object_id = p.OBJECT_ID 
                    AND i.index_id = p.index_id
INNER JOIN 
    sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN 
    sys.schemas s ON t.schema_id = s.schema_id
WHERE 
    t.NAME NOT LIKE 'dt%' 
    AND t.is_ms_shipped = 0
    AND i.OBJECT_ID > 255 
GROUP BY 
    t.Name, s.Name, p.Rows
ORDER BY 
    t.Name

Efter at have kørt dette script i SSMS, fik jeg en fornemmelse af, at problemet havde med versionering af dokumenterne at gøre. De tabeller som indeholdte markant mere data end forventet, var cmsContentVersion, cmsDocument, cmsPropertyData og umbracoLog. Uden at ville (og kunne) gå i yderligere detaljer om, hvad disse tabeller konkret bruges til, indikerer det i det mindste, at det har noget med versionering at gøre. Spørgsmålet er bare, hvorfor? Der er ikke specielt meget aktivitet i relation til vedligeholdelse af indhold på sitet, så hvorfor er der oprettet så mange rækker i disse tabeller (der var over 500.000 i cmsDocument og cmsContentVersion og over 3.500.000 i cmsPropertyData, ligesom der også var omkring 1.200.000 i umbracoLog...!

Et kig i umbracoLog afslører en periodisk publisering af to specifikke dokumenter, som resulterer i 4 nye rækker i umbracoLog, samt nye 2 eller flere rækker i hver af de andre tabeller, hver gang. Hver gang vil sige, hvert minut 24/7/365 - det bliver til en del rækker med tiden... :-)

Det var naturligvis ikke en optimal situation, så der måtte da være en løsning på dette. Hvorfor blev disse to dokumenter (indholdssider på linje med en masse andre på sitet) publiseret med 1 minuts intervaller og mere vigtigt, hvordan fik jeg det så stoppet!?

"Løsningen"

Derfor måtte jeg finde ud af, hvordan jeg kunne løse dette. Google er min ven(!), men selv venner har sine begrænsninger, så det lykkedes den ikke at fremskaffe en løsning. Den eneste tilnærmelsesvis overkommelige løsning var, at opgradere til en nyere version, hvor dette ikke længere var et problem. Det lader nemlig til at være et bug i nogle versioner (herunder v3.0.6, som dette site jo kører), som bevirker, at der publiseres på denne måde.

Jeg skal erkende, at jeg heller ikke har søgt efter en løsning meget mere end en times tid, da sitet skulle pilles ned indenfor en overskuelig tidshorisont, så det kan være der rent faktisk kan køres et workaround, som løser dette, men jeg er som sagt ikke faldet over det.

Det jeg så gør i stedet, er symptombehandling (when all else fails...). Det indbefatter en periodisk udførsel af et SQL script, som sletter alle versioner op til en bestemt dato (i nedenfor viste script, er det til dagen før den dato hvorpå scriptet udføres) og som ikke er den aktive version. Dette script ser således ud.

DECLARE @createdDate Datetime
SET @createdDate = DateAdd(day, -1, getdate())

DELETE FROM cmsPropertyData WHERE
    versionId NOT IN (
              SELECT versionId 
              FROM cmsDocument 
              WHERE updateDate > @createdDate 
                 OR published = 1 
                 OR newest = 1) AND
    contentNodeId IN (SELECT DISTINCT nodeID FROM cmsDocument)

DELETE FROM cmsContentVersion WHERE
    versionId NOT IN (
              SELECT versionId 
              FROM cmsDocument 
              WHERE updateDate > @createdDate 
                 OR published = 1 
                 OR newest = 1) AND
    ContentId  IN (SELECT DISTINCT nodeID FROM cmsDocument)

DELETE FROM cmsDocument WHERE
    versionId NOT IN (
              SELECT versionId 
              FROM cmsDocument 
              WHERE updateDate > @createdDate 
                 OR published = 1 
                 OR newest = 1) AND
    nodeId IN (SELECT DISTINCT nodeID FROM cmsDocument)

Dette script, når det bliver gemt som en fil og placeret på serveren, kan så, med jævne mellemrum, aktiveres, som en baggrundsopgave på serveren, hvor scriptet kaldes med sqlcmd.

sqlcmd -S myServer\instanceName -i C:\sqlscripts\umbracoCleanup.sql

Konklusion

Nu har jeg i det mindste fået lidt styr på databasevæksten på mit site, selvom jeg ikke synes dette er den optimale løsning (langt fra - det bedste ville jo være, at publiseringen ikke gik i selvsving!). Nogle gange er vi bare nød til, at nøjes med mindre, så vi kan komme videre med det der er rigtig fedt! :-)

Det er ofte et krav, at der skal kunne uploade filer til en webapplikatione. Dette er heldigvis ret let, når der er tale om en ASP.NET webapplikation. Det giver dog til tider lidt problemer, når der skal kunne uploades større filer (over 4 Mb), men ikke større end at det også kan løses. Jeg vil her kort beskrive en løsning.

Ændr indstillingerne

Det er faktisk ikke mere kompliceret end, at ændre indstillingerne i web.config. Helt konkret er det elementet httpRuntime (som ligger under system.web-elementet), der skal ændres således:

<httpRuntime 
    maxRequestLength="8096" 
    requestTimeout="120" 
    requestLengthDiskThreshold="8096" />

Hvis du kører på en IIS 7+ skal du muligvis også tilføje  security-elementet (som ligger under sektion system.webServer-elementet) således:

<security>
  <requestFiltering>
    <requestLimits maxAllowedContentLength="8096000" />
  </requestFiltering>
</security>

Nu skulle du være i stand til at uploade 8 Mb i stedet for 4 Mb. Husk at requestTimeout skal være længere end den længste forventede tid der går fra en klient starter upload til det er færdigt, ellers fejler uploadoperationen med timeout i stedet.

Advarsel

Vær også opmærksom på, at højre grænser for mængden af data der kan sendes til en side i din webapplikation, kan have alvorlige konsekvenser for din sårbarhed overfor DOS-angreb, da det bla. vil optage en tråd i puljen indtil data er modtaget og behandlet. Mange af denne slags kald vil derfor risikere vil udsulte puljen af tråde til at behandle requests, hvilket medfører, at din applikation er nede. Derfor skal det overvejes nøje, hvis denne grænse sættes op til store værdier. Jeg har ikke fået undersøgt, om dette kan afbødes med async/await, men det var måske en mulighed. Dog vil du måske stadig ende med en ekstraregning for trafik efter et DOS-angreb af denne slags...

Se også

http://forums.asp.net/t/1810854.aspx er en tråd med reflektioner omkring dette emne og inspirationskilden til dette indlæg.

Jeg vil, i tilfælde med indhold som ikke eksisterer, gerne returnere en side med statuskoden 404 (af hensyn til SEO), men samtidig gerne have, at siden ikke er en standard 404-side. Dette sker som udgangspunkt ikke i ASP.NET MVC3, da MVC 3 kobler en standard handler på fejlsider. Dette er også helt fint, men i disse særlige tilfælde, hvor jeg gerne selv vil styre 404-siden, er det træls.

Efter lidt søgen rundt på nettet (primært StackOverflow), fandt jeg, i en kommentar til et indlæg, en henvisning til denne egenskab på Response-objektet:

Response.TrySkipIisCustomErrors = true;

Den sørger åbenbart for, at den standard handler som er opsat, ikke aktiveres, når jeg sætte Response.StatusCode = 404.

Dermed kan jeg med følgende kode i min Controller's Action, få vist en ikke standard 404-side (som, i mit tilfælde, ligger i et view med navnet "NotFound"):

public ActionResult View(int id)
{
   Response.Status = "404 - Not Found";
   Response.StatusCode = 404;
   return View("NotFound");
}

Jeg kunne måske endda pakke denne kode ind, så jeg kan kalde den fra forskellige controllers, som så kunne have deres egne specialiserede views til NotFound-håndtering...

Har man arbejdet med ASP.NET MVC 4, ved man der findes en bundling og minification mulighed indbygget i frameworket. Dette er umiddelbart nyt ifht. MVC 4 og fandtes ikke som udgangspunkt i MVC 3.

Man kan dog benytte sig af disse features i et MVC 3-projekt, hvis man benytter .NET 4, man skal bare lige selv sætte de grundlæggende ting op i sit projekt (registrering af bundles, inkludering af System.Web.Optimization og kald af bundles i sit layout).

Du kan finde en nærmere forklaring til dette i artiklen om "Using MVC 4 bundling and minification in an MVC 3 project".

Se også

Denne artikel på MSDN er endnu mere uddybende omkring emnet.

"Javascript minification in MVC 3" kommer også ind på, hvordan man kan overstyre bundling- og minificationprocessen, så man kan smide sine egne regler ind i mix'et.

Hvis du arbejder med webforms kan du måske få lidt ud af kigge på, hvordan man kan benytte scriptmanager til at kombinere scriptfiler.

Jeg arbejder på en webapplikation der skal køre i Azure og jeg har dermed også behov for at kunne teste lokalt.

Mit setup er:

• Visual Studio 2012
• ASP.NET MVC 3
• .NET 4.0
• Windows 8 Pro x64
• fuld IIS 8

Denne webapp skal køre en del af sitet over SSL, så derfor har jeg fået sat mit udviklingsmiljø op til at benytte SSL, hvilket umiddelbart også fungerer.

Jeg har dog oplevet lidt problemer med, at uploade filer over SSL. Dette kan nok skyldes mange ting, men umiddelbart udmynter det sig i, at jeg får en 404 tilbage, når jeg POST'er filen til en, 100% sikkert, eksisterende action på min controller. Først troede jeg det havde noget med mine routing at gøre, men GET-request til samme action fungerer jo, så jeg har udelukket denne mulighed.

Jeg har endnu ikke fundet en løsning på dette problem, men jeg har fundet et workaround.

Det jeg gør er, i stedet for at køre over den localhost IP, som IDE'en starter min browser på (https://127.0.0.1/), så kører jeg over den localhost IP som IIS manageren peger på, nemlig https://127.255.0.0:444/. 

Porten kan dog variere, men hvis man lurer i Output-vinduet af VS, når Emulatoren startes (ifm. build and run), skal man bruge det private portnummer, hvilket kan ses i den linje hvor der står

Windows Azure Tools: Warning: Remapping private port 443 to 446 in role...

Når jeg gør det, lader det til at min action bliver aktiveret korrekt og filen bliver uploadet som den skal.

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)...