Tänkte snabbt bara... Kanske är knasigt men.
Kan du göra en kontroll som lägger in din css med build nr. ?
kontrollen laddar bara:
<link rel="stylesheet" type="text/css" href="controls.css?rev=<ditt app.buildVersion>"/>
6 svar · 1 278 visningar · startad av dAEk
Då och då behöver man ändra sin markup och CSS och eftersom man vill cacha sin CSS behöver man någon form av versionshantering så att ens besökare alltid använder den senaste versionen, annars är risken stor att den cachade versionen används och saker och ting överlappar, visas i fel storlek, färg osv.
Supervanligt problem men hur löser man det i asp.net?
Jag vill helst undvika att gå in och ändra sökvägarna eller lägga in en wrapper (servertag). Istället tänker jag mig att det borde funka med en HttpHandler som använder en appSetting (t.ex. "app.buildVersion") vars värde inkrementeras vid varje publicering/deployment/app_onstart. Handlern ansvarar sedan för att modifiera outputten och lägga till värdet i ens sökvägar. Då kan man sätta sina cache-headers långt fram i tiden och trots det kommer webbläsarna "luras" till att använda den senaste versionen.
Men... eftersom jag inte har koll på alla koncept inom asp.net har jag säkert missat något.
Hur gör ni? Finns det andra, bättre metoder?
Tänkte snabbt bara... Kanske är knasigt men.
Kan du göra en kontroll som lägger in din css med build nr. ?
kontrollen laddar bara:
<link rel="stylesheet" type="text/css" href="controls.css?rev=<ditt app.buildVersion>"/>
Kör du MVC eller Webforms, använder du cont. integration?
Trodde faktiskt att det skulle droppa in fler svar än bara två. Ställde jag frågan fel eller nåt?
@Martin: Jo, det där funkar så klart men det är så jag egentligen inte vill göra. Det måste finnas bättre sätt!
Vi får se, jag har funderat på att introducera (N)Ant för de andra men jag är lite halvskeptisk till hur det kommer bemötas. Jag vet inte, det kan vara svårt att se behovet och rätt krångligt i början när man inte är van att jobba med det men jag saknar det, även fast jag inte är nå vidare på byggskript.
Det går att göra samma sak (och mer därtill) med NAnt, det är därför jag tar upp det. Tänkte försöka samla på mig ett par bra argument först och sen får vi se hur det blir med den här frågan men jag är fortfarande intresserad av hur ni andra gör.
Trevlig kväll :bire
/r:
@erka: Vi kör med WebForms.
en gång för länge sen gjorde jag nån funktion som la till en slumpad siffra, eller tiden i millisekunder, i filnamnet. därav skapades alltid en ny fil i cachen, men det var inte css-filen, kanske är annorlunda... kan det vara nåt?
Är väl ungefär det som sagts: http://www.webforum.nu/showthread.php?t=145456
Annars rent allmänt.
Klienten skicka en HTTP header "If_Modified_Since" inkl datum som klienten cachat filen, som webbservern jämför med den fil som efterfrågas i GET. Är filen på servern modifierad senare än det värde som klienten anger, skickas en ny fil till klienten och anger HTTP kod 200. Om filen på servern inte är modifierad efter klienten värde, skickas 304 Not modified. Och som din problemställning säger: ibland skickar servern 304 fast filen faktiskt är ändrad.
1. Så antingen kan du appenda fil.css?<uniqe-value> till filen för gå runt serverns cachning av fil.css och alltid returnera 200 (den fräscha filen).
2. Appenda fil.css?<version-value> till filen för gå runt serverns cachning endast vid versionsbyte.
3. Du kan eventuell konfigurera din server att inte cacha den filen/filtypen alls. ( Apache i stil med ExpiresByType text/css “access plus 1 second” )
4. Låt din css-fil vara en server exekverad fil (.php,asp,...) och sätt passande no-cache header vilken gör att filen aldrig cachas.
Kan nämnas att alla utom 2:an förmodligen slöar ner din webbtjänst i någon grad.
[...]
(Kapat för att det inte ska bli så köttigt)
Jag vet inte om jag vill in och ändra i IIS:ns cacheinställningar för jag kan inte säga att jag har koll på vilka ovälkomna effekter det kan bli. Om jag ändå skulle vilja gå in och pilla i IIS:n, kan man ändra cache-inställningarna per filtyp och går det att göra det globalt eller gör man det per sajt? Det vore hur som helst trevligt om man kom undan manuellt jobb.
Angående förslagen: Mja, mjo, nja..
1 och 2)
Jo, men det funkar inte om man använder @import i sina CSS-filer. De filerna kommer inte kunna använda versionsnumret. Hur blir det med embeddade CSS-filer (WebResources)? Inte för att vi kör med sådana vad jag vet, men ändå. Det var därför jag kom in på att använda en handler som parsar HTML-koden innan den skickas iväg till webbläsarna. Då behöver man iofs konfa servrarna också vilket egentligen inte är nåt problem men som sagt, det vore sjyst om man slapp manuella ingrepp.
Det är inte ett alternativ.
Det är inte ett alternativ.
Att det finns så många olika sätt att infoga CSS/JS förvirrar mig. Det i kombination med att man ibland vill in och pilla i CSS:n på servern utan att behöva deploya om hela appen. Visst är det lite fy! att göra så men ibland är man lat. Risken att man glömmer checka in ändringen i SVN - ja, den finns där.
Samtidigt som jag funderar på den här frågan är jag ute efter att minska HTTP-anropen genom att slå ihop filerna till en. Man skulle kunna utgå ifrån att alla filer i en mapp kan slås ihop och få ett versionsnummer eller MD5-summa. Fast då får man inte generera CSS med en Handler...
Nåja, det kanske är bäst att utgå ifrån de projekt man själv är inblandad i. Visst skulle det vara trevligt att fixa en lösning som täcker en massa olika scenarion men man kan inte få allt. Fast det vore sjyst... ;)