Hela ämnet med projekt, lösningar och filer och verktyg som styr dem är något som sällan förklaras.
Kasta mat
En av de stora fördelarna med vägen Microsoft har utformat lösningar och projekt är att ett projekt eller lösning är fristående. En lösningskatalog och dess innehåll kan flyttas, kopieras eller raderas i Windows Explorer. Ett helt team av programmerare kan dela en fil (.sln); en hel uppsättning projekt kan ingå i samma lösning, och inställningarna och alternativen i den .sln-filen kan tillämpas på alla projekt i den. Endast en lösning kan vara öppen samtidigt i Visual Studio, men många projekt kan vara i den lösningen. Projekten kan till och med vara på olika språk.
Du kan få en bättre förståelse för vad en lösning är genom att skapa några och titta på resultatet. En "tom lösning" resulterar i en enda mapp med bara två filer: lösningsbehållaren och lösningsanvändaralternativen. Om du använder standardnamnet ser du:
Lägg till sekretess
Det främsta skälet till att du kan skapa en tom lösning är att låta projektfiler skapas oberoende och inkluderas i lösningen. I stora, komplexa system, förutom att de ingår i flera lösningar, kan projekt till och med kapslas i hierarkier.
Intressant är lösningsbehållarfilen en av de få textkonfigurationsfiler som inte finns i XML. En tom lösning innehåller dessa uttalanden:
Det kan lika bra vara XML... det är organiserat precis som XML men utan XML-syntax. Eftersom detta bara är en textfil är det möjligt att redigera den i en textredigerare som Notepad. Du kan till exempel ändra HideSolutionNode = FALSE till TRUE och lösningen visas inte längre i Solution Explorer. (Namnet i Visual Studio ändras också till "Project Explorer".) Det är bra att experimentera med sådana saker så länge du arbetar med ett strikt experimentellt projekt. Du bör aldrig ändra konfigurationsfiler manuellt för ett riktigt system om du inte vet exakt vad du gör, men det är ganska vanligt i avancerade miljöer att uppdatera .sln-filen direkt snarare än genom Visual Studio.
.Suo-filen är dold och den är en binär fil så att den inte kan redigeras som .sln-filen. Du kommer normalt bara att ändra den här filen med menyalternativen i Visual Studio. Gå upp i komplexitet och kolla in en Windows Forms-applikation. Även om detta kan vara den mest elementära applikationen finns det mycket fler filer.
Förutom en .sln-fil skapar Windows Forms Application-mallen också automatiskt en .vbproj-fil. Även om filerna .sln och .vbproj ofta är användbara kanske du märker att de inte visas i Visual Studio Solution Explorer-fönstret, även med knappen "Visa alla filer". Om du behöver arbeta med dessa filer direkt måste du göra det utanför Visual Studio.
Inte alla applikationer behöver en .vbproj-fil. Om du till exempel väljer "Ny webbplats" i Visual Studio skapas ingen .vbproj-fil. Öppna den översta mappen i Windows för Windows Forms-applikationen så ser du de fyra filerna som Visual Studio inte visar. summa standardnamnet igen, de är: .sln- och .vbproj-filerna kan vara användbara för att felsöka svåra problem. Det är ingen skada att titta på dem och dessa filer berättar vad som är verkligen pågår i din kod.
Som vi har sett kan du också redigera .sln- och .vbproj-filer direkt även om det vanligtvis är en dålig idé om det inte finns något annat sätt att göra det du behöver. Men ibland finns det inget annat sätt. Till exempel, om din dator körs i 64-bitarsläge, finns det inte ett sätt att rikta in sig på en 32-bitars CPU i VB.NET Express till exempel för att vara kompatibel med 32-bitars Access Jet-databasmotorn. (Visual Studio erbjuder ett sätt i de andra versionerna), men du kan lägga till följande:
Till elementen