En lite knepig grej är hur Visual Studio väljer att organisera filer när man gör nya projekt. Säg att du har gjort en folder som heter DotNetProjects där du vill lagra alla dina olika programmeringsprojekt. Sedan skapar du ett nytt Web Site-project enligt följande; 
Nu skapas självklart en mapp under DotNetProjects som heter MyWebsite. Men dessutom skapas följande katalog under Mina Dokument; 
Här placeras en .sln-fil som symboliserar din solution. En solution kan innehålla flera WebSites, WinForm-program, Class Libraries etc. Mer om det strax. Dessutom finns här en .suo-fil som håller koll på Visual Studio-inställningar för just denna Solution (och programmerare).
En viktig poäng här är att dessa filer inte på något sätt behövs för att du ska kunna jobba med ditt WebSite-projekt. Du kan välja File -> Open Website... och peka ut C:\DotNetProjects\MyWebsite för att öppna upp och jobba med WebSite-projektet. Om du tar bort .sln- och .suo-filerna kommer Visual Studio skapa nya nästa gång du öppnar och sparar projektet.
.sln-filen är dock bra att ha koll på. Bland annat eftersom det är den Visual Studio länkar till under Recent Projects på StartPage-fliken; 
Dessutom håller .sln-filen koll på vilka filer du hade öppna senast du jobbade med projektet, vilket kan vara smidigt när man ska fortsätta där man senast slutade.
Så för att få en bättre koppling även i filsystemet mellan .sln-filen och själva projektet brukar jag göra följande:
- Skapa en Blank Solution
- Lägga till projekt, som jag placerar under den katalognivå där jag placerat .sln-filen.
Innan vi kikar på detta gör jag om min grundläggande katalogstruktur enligt följande; 
Som du ser har jag lagt till en Rot-nivå, flyttat in DotNetProjects och döpt om den till DotNetSolutions för att bättre stämma överens med Visual Studios terminologi. Anledningen till denna rotnivå återkommer jag till.
Nu skapar jag en Blank Solution enligt följande: 
Notera att jag i vänsterkolumnen navigerat mig till Other Project Types -> Visual Studio Solutions för att hitta mallen Blank Solution. Notera också att jag med Browse...-knappen pekat ut min DotNetSolutions-mapp.
Nu skapas ingenting annat än en helt tom solution, Solution Explorer ser ut så här: 
Och i Utforskaren ser det ut så här: 
Nu vill jag ordna så att MyWebsite blir ett WebSite-projekt som hör till MyWellOrganisedSolution. Jag börjar med att flytta in mappen MyWebsite i mappen MyWellOrganisedSolution; 
Sedan går jag tillbaka till Visual Studio och gör enligt följande; 
Redan vid mappförflyttningen ovan åstadkom vi att filsystemet speglar att MyWebsite är en del av MyWellOrganisedSolution. Genom detta sista steg är det så även enligt Visual Studio och .sln-filen; 
Nu kan vi också städa bort den uppsättning .sln/.suo-filer Visual Studio skapade när vi först skapade MyWebsite; 
(Testa gärna att dubbelklicka på denna MyWebsite.sln innan du tar bort mappen, Visual Studio kommer inte att hitta WebSite-projektet MyWebsite då det har flyttats sedan vi skapade det)
Ett inte helt ovanligt scenario är att man har projekt som ska ingå som en del i flera andra projekt. Det kan vara projekt man gör själv, eller något delat projekt som exempelvis AjaxControlToolkit. "Projekt?" kanske du tänker nu, ja men visst består AjaxControlToolkit av projekt, låt oss kika på katalogstrukturen för AjaxControlToolkit (Ladda hem Ajax Control Toolkit, välj AjaxControlToolkit-Framework3.5.zip); 
Om du kikar i mappen AjaxControlToolkit kommer du hitta en fil som heter AjaxControlToolkit.csproj. Detta är ett Visual Studio-projekt som är ett Class Library, varje mapp innehåller klasser och andra filer som utgör en kontroll i toolkitet. Det finns dessutom en bin-mapp där toolkitets dll-fil ligger. Detta är den kompilerade versionen av toolkitet, som andra projekt behöver för att kunna använda sig av kontrollerna i toolkitet.
Om du kikar i mappen SampleWebSite så kommer du se att den innehåller mappar som App_Code, App_Data och filer som Default.aspx och web.config. Denna mapp går alltså att öppna via File -> Open -> Web Site... (Eller så kan du se AjaxControlToolkit här, det är exakt samma website).
Om du kikar direkt i rotmappen, AjaxControlToolkit-Framework3-5, kommer du hitta en .sln-fil som kapslar in båda dessa projekt och några till som ingår när man laddar hem AjaxControlToolkit. Ok, detta var ett litet sidospår samtidigt som det var repetition ;-)
Det som kan vara intressant för våran MyWebsite är förstas klassbiblioteket AjaxControlToolkit. Men detta projekt är ju antagligen intressant att också inkludera i andra solutions man gör, så därför känns det fel att kopiera denna mapp in i mappen MyWellOrganisedSolution. Därav rotnivån jag skapade för mina DotNetSolutions tidigare, jag skapar nu en ny mapp kallad Library och där i placerar jag hela AjaxControlToolkit enligt följande; 
Tänk på mappen Library som ett bibliotek av projekt som kommer att användas av mer än en av dina solutions.
Nu kan jag lägga till AjaxControlToolkit till MyWellOrganisedSolution så här; 
Markera AjaxControlToolkit.csproj och klicka Öppna. En dialogruta visas där du får välja mellan Load project for browsing/Load project normally. Du måste välja det senare om du har behov av att ändra i det projekt du lägger till och i princip kan du alltid göra det så länge källan till projektet är tillförlitlig.
Nu finns båda projekten i Solution Explorer; 
Du kan nu öppna upp filerna under AjaxControlToolkit och om du vet vad du gör kan du ändra på befintliga kontroller och kanske rentav skapa egna(!). Och om du gör det och lägger till AjaxControlToolkit på liknande sätt i en annan WebSite-solution kommer det vara samma filer du redigerar i oavsett vilken solution du just då har öppen.
För att du ska kunna använda AjaxControlToolkit i MyWebsite måste dock ytterligare en sak göras. Högerklicka på MyWebsite och välj Add Reference...; 
I dialogrutan som öppnas, välj fliken Projects; 
Här visas en lista över alla övriga projekt i aktuell solution (just nu finns det ju bara ett) och du kan alltså enkelt välja AjaxControlToolkit. Det som händer när du gör det är att det projektets dll-fil kopieras till MyWebsite-projektets bin-mapp; 
Om du ändrar något i AjaxControlToolkit (tänk på att detta också gäller om du lagt till ett eget klassbibliotek) måste du högerklicka på solution-noden och välja Rebuild Solution innan ändringarna slår igenom i MyWebsite.
Låt oss ta en snabb koll på ett eget Class Library också, i detta fall som ett projekt som bara kommer att användas av MyWebsite. Att göra ett separat Class Library istället för att placera kod-filer i App_Code gör bland annat att kompilering går snabbare, läs mer om det här.
Så, vi lägger till ett nytt projekt: 
Notera att jag väljer att placera detta projekt under MyWellOrganisedSolution i filsystemet, eftersom detta projekt endast kommer att användas av MyWebsite, som man kan säga är huvudprojektet i denna Solution.
Min solution har nu följande struktur; 
Lägg till en referens till MyClassLibraryForMyWebsite i MyWebsite, precis som du gjorde med AjaxControlToolkit. Därefter kan du lägga till x antal cs-filer i MyClassLibraryForMyWebsite och de kan användas av MyWebsite på precis samma sätt som om de hade legat i App_Code. Och som sagt, läs om skillnaden här.
No comments :
Post a Comment