18 svar · 509 visningar · startad av anbj
Jag bygger förnärvarande ett intranät med ett gäng olika moduler i som används av olika användare i organisationen. Mitt problem just nu är att jag inte kan bestämma mig för om jag ska göra allt det här i ett project i VS.NET eller om jag ska dela upp det på flera projekt (lite meckigt men det går).
Det jag vill uppnå är att kunna uppdatera en modul på intranätet utan att störa övriga moduler. Självklart är detta oundvikligt om det det rör sig om uppdateringar av kod som alla moduler använder. Men om man har gjort förändringar inom en viss modul så vill jag kunna deploya enbart den utan att störa övriga.
Vilket är smidigast för detta syftet? Kör jag i ett project får jag ju en enda fet dll som jag måste kopiera varje gång jag har gjort en ändring någonstans (oavsett modul)...
Kör jag flera project känns det rörigare med referenser osv, men jag får å andra sidan flera separata dll:er...
Några erfarenheter av det här?
Mycket bra fråga.
Jag tror jag skulle jobbat med ett projekt. Tror det är enklast så. Och sedan infoga klassbiblotek och sedan försöka avgänsa modulerna med tex kataloger och liknande.
Så skulle jag gjort, varför vet jag inte riktigt men det känns som ett sammlat sätt att arbeta på.
Tänk att du i framtiden kanske även vill bygga en Windows applikation, då är det kanske inte så vettigt att ha allt liggandes i ett och samma projekt då du får med användarkontroller och usercontrols, vilket du inte har någon som helst nytta av i din windows applikation, när du skapar en referens till projektet.
Jo men all logik lägger man i klassbiblotek. Vilket iofs är projekt i sig. Men det är det ända...jag skulle nog inte göra en websolution för varje modul.
Dock beror det väldigt mycket på situationen, ibland är det önskvärt att bygga mer generella kontroller och ibland mer specifika kontroller. Det jag ivll ha sagt är att det beror mycket på situation hur många projekt man ska dela upp sin applikation i, planerar man att återanvända vissa delar i andra projekt är det självklara valet att lägga dessa i ett eget projekt.
Det är definitivt inte svårt att arbeta med flera projekt i vs.net, allt som behövs är ju en referens. Så frågar du mig är valet självklart - ett webbprojekt och sedan har du precis som asmodie skriver klassbibliotek, eventuella egenkonstruerade kontroller osv runt detta som ju då är egna projekt. Skalbart och fint!
Menar ni att man ska ha ett webbprojekt och sedan ändra code-behind referensen för en viss moduls sidor till att peka på ett annat klassbibliotek? Kan man isf ställa in detta som default på något sätt så man slipper ändra inherits i toppen av varje ny aspx sida för den modulen?
Eller har jag missuppfattat er helt?
Du har ett webbprojekt som innehåller alla webbsidor. I ditt webbprojekt lägger du sedan en referens till var och en av dina övriga projekt som du vill inkludera i projektet. Detta behöver du naturligtvis bara göra en gång. Sedan arbetar du med namespace precis på samma sätt som du använder det befintliga klassbiblioteket på dina sidor. Det är alltså inte svårare att använda dina egna klasser och metoder än att använda ToString(). :)
Jag är med på att det är smidigt att ha fristående klassbibliotek för gemensamma funktioner. Men mitt problem är att jag vill kunna uppdatera separata moduler (forummodul, nyhetsmodul etc) utan att övriga delar av intranätet störs.
Jag kan ju då ha flera olika webprojekt i en solution och ha referenser fram och tillbaka och får då olika dll:er för varje webprojekt.
Eller så kan jag ha ett webprojekt med alla moduler i och ett klassbibliotek med gemensamma funktioner, men då får jag fortfarande en dll för alla moduler och en dll för alla gemensamma funktioner.
Eftersom VS.NET automatiskt skapar klassfilen (fil.aspx.vb) och referens till den på aspx sidan så känns det bökigt att ha all logik för en aspx sida i ett separat klassbibliotek. Då måste det vara enklare att bita i det sura äpplet och köra flera webprojekt i en solution.
Eller har jag fel??
Eftersom VS.NET automatiskt skapar klassfilen (fil.aspx.vb) och referens till den på aspx sidan så känns det bökigt att ha all logik för en aspx sida i ett separat klassbibliotek. Då måste det vara enklare att bita i det sura äpplet och köra flera webprojekt i en solution.
Nja, en sida (aspx) i sig har ingen referens till andra assemblys, referenserna finns på projektnivå, så jag vet inte riktigt varför det skulle bli bökigt? Eller hur menade du? Om du lägger till en referens till ditt projekt "Project.News" som innehåller funktionen "GetNews()" så kan du nå funktionen från ALLA sidor i ditt webbprojekt precis på samma sätt som du når funktioner och metoder i .nets egna klassbibliotek (Project.News.GetNews()). Det betyder ju dock inte att du helt ska ta bort den klassfil som hör till den aktuella sidan, funktionsanrop och kod nära presentationslagret ligger ju kvar lokalt, du kommer att arbeta med flera skikt. Jag menar alltså inte att du ska lägga precis all logik utanför ditt webbprojekt, funktionen GetNews ska inte fylla en datagrid lokalt på din sida utan returnera en collection som du kan använda lokalt för att fylla din datagrid!
Att uppdatera ett .net webbprojekt är tämligen säkert, det fungerar nämligen så (om jag förstått det rätt) att den nya dll:en kommer att arbeta parallellt med den gamla så länge det finns användare som använder denna. Du kan alltså lungt lägga upp en ny dll även om det är många användare på siten utan att riskera att någon användare får problem och tappar information! Den störning som blir är att så fort du laddar upp en ny assembly är att sidorna kommer att "byggas om" till den nya, den användare som tar första exekveringen kommer alltså att få en ganska lång svarstid.
Okej, nu börjar jag förstå hur du menar. Om det är som du säger att det är riskfritt att ladda upp en ny dll fast det finns användare på siten så är ju mina problem ur världen. Vissa moduler är nämligen väldigt kritiska och det är bra om man kan undvika att påverka dessa när man ändrar i andra.
Jag får läsa på mer om hur asp.net hanterar uppdatering av dll:er vid drift. Det enda jag har upptäckt som kan ställa till det är att sessioner tappas när man komplierar om kod. Men det kanske man kan komma runt?
Although ASP.NET cannot prevent the common language runtime from locking a loaded assembly DLL on disk, it can support you by ensuring that the physical DLLs in a Web application's private assembly cache are never actually loaded by the runtime. Instead, shadow copies of the assembly DLLs are made immediately prior to their use. These shadow assemblies--not the original files--are then locked and loaded by the runtime.
Because the original assembly files always remain unlocked, you are free to delete, replace, or rename them without cycling the Web server or having to use a registration utility. FTP and similar methods work just fine.
Den störning som blir är att så fort du laddar upp en ny assembly är att sidorna kommer att "byggas om" till den nya, den användare som tar första exekveringen kommer alltså att få en ganska lång svarstid.
Och om du har en sajt med väldigt mycket besökare och vill slippa ovanstående så kan du använda "ngen" (Native Image Generator) som kommer med VS för att "förkompilera" dina assamblies innan du lägger ut dem.
Då kommer första användaren bara behöva vänta på att dll.en ska cachas och inte på kompileringen.
Tack för den texten, det låter ju himla bra. Jag har labbat lite och det är ju bara ett aber, och det är att sessioner som sagt försvinner när man ersätter en dll. Så återigen, om man har en dll för alla sina moduler och man byter ut den för att man har ändrat något i en modul så kommer det betyda att alla användare loggas ut i mitt fall (jag kollar om man är inloggad mot en sessionsvariabel).
Men man kanske får leva med detta helt enkelt....
Som jag har förstått det så kan du byta en dll under drift utan några som helst problem. Inga sessioner försvinner eftersom de använder som använder din gammla dll kommer att fortsätta med det tills deras sessioner dör och alla ny besökare får din nya dll, alltås så fasas din nya dll in sakt med säkert.
Så du skall kunna byta en dll under drift utan några störningar.
- M
Inga sessioner försvinner eftersom de använder som använder din gammla dll kommer att fortsätta med det tills deras sessioner dör och alla ny besökare får din nya dll, alltås så fasas din nya dll in sakt med säkert.
Jo, så ska det fungera om jag förstått det rätt... tyvärr verkar teori och praktik inte gå hand i hand i det här fallet, jag testade precis och mycket riktigt... sessionerna försvinner. :( Någon som har en lösning?
Från https://www.devx.com/dotnet/Article/10045
So to update a Web application you can simply copy the updated files to the correct location, and ASP.NET automatically handles shutting down the running application and copying the shadow files.
Om texten stämmer så startas alltså applikationen om när man kopierar över nya filer, då försvinner ju sessioner vare sig man vill eller inte. Tror inte att det går att undkomma.....
Jo, men som jag förstått det ska det fungera så att alla användare som redan är påloggade på sidan innan uppdateringen ska fortsätta använda den gamla assemblyn parallellt med den nya, de ska alltså inte påverkas av uppdateringen förrän de loggar in på nytt. Den gamla assemblyn ska finnas kvar så länge det finns användare som använder den!
Efter lite ytterliggare efterforskningar så kan man komma runt problemet genom att använda StateServer eller SQL Server för att hantera sessioner. Någon som har erfarenhet av detta? Är det långsammare, snabbare, krångligare??
Läs mer här:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfsessionstatesection.asp
