Hele emnet med projekter, løsninger og filer og værktøjer, der kontrollerer dem, er noget, der sjældent forklares.
At kaste mad
En af de store fordele ved vejen Microsoft har designet løsninger og projekter er, at et projekt eller en løsning er selvstændig. En løsningskatalog og dens indhold kan flyttes, kopieres eller slettes i Windows Stifinder. Et helt team af programmerere kan dele en løsningsfil (.sln); et helt sæt projekter kan være en del af den samme løsning, og indstillingerne og indstillingerne i den .sln-fil kan gælde for alle projekterne i den. Kun en løsning kan være åben ad gangen i Visual Studio, men mange projekter kan være i den løsning. Projekterne kan endda være på forskellige sprog.
Du kan få en bedre forståelse af, hvad en løsning er ved at skabe nogle få og se på resultatet. En "Blank løsning" resulterer i en enkelt mappe med kun to filer: løsningsbeholderen og løsningsbrugerindstillingerne. Hvis du bruger standardnavnet, ser du:
Tilføj privatliv
Hovedårsagen til, at du kan oprette en tom løsning, er at tillade, at projektfiler oprettes uafhængigt og inkluderet i løsningen. I store, komplekse systemer kan projekter ud over at være en del af flere løsninger endda indlejres i hierarkier.
Interessant er løsningsbeholderfilen en af de få tekstkonfigurationsfiler, der ikke er i XML. En tom løsning indeholder disse udsagn:
Det kan lige så godt være XML... det er organiseret ligesom XML, men uden XML-syntaks. Da dette kun er en tekstfil, er det muligt at redigere den i en teksteditor som Notepad. For eksempel kan du ændre HideSolutionNode = FALSE til SAND, og løsning vises ikke længere i Solution Explorer. (Navnet i Visual Studio ændres også til "Project Explorer"). Det er fint at eksperimentere med ting som dette, så længe du arbejder på et strengt eksperimentelt projekt. Du bør aldrig ændre konfigurationsfiler manuelt for et rigtigt system, medmindre du ved nøjagtigt, hvad du laver, men det er temmelig almindeligt i avancerede miljøer at opdatere .sln-filen direkte i stedet for gennem Visual Studio.
.Suo-filen er skjult, og det er en binær fil, så den kan ikke redigeres som .sln-filen. Du ændrer normalt kun denne fil ved hjælp af menuindstillingerne i Visual Studio. Gå op i kompleksitet og tjek en Windows Forms-applikation. Selvom dette muligvis er den mest elementære applikation, er der meget flere filer.
Foruden en .sln-fil opretter Windows Forms Application-skabelonen også automatisk en .vbproj-fil. Selvom .sln- og .vbproj-filerne ofte er nyttige, kan du bemærke, at de ikke vises i Visual Studio Solution Explorer-vinduet, selv med knappen "Vis alle filer" klikket. Hvis du har brug for at arbejde direkte med disse filer, skal du gøre det uden for Visual Studio.
Ikke alle applikationer har brug for en .vbproj-fil. Hvis du for eksempel vælger "Nyt websted" i Visual Studio, oprettes ingen .vbproj-fil. Åbn mappen på øverste niveau i Windows til Windows Forms-applikationen, og du vil se de fire filer, som Visual Studio ikke viser. Når man antager standardnavnet igen, er de: .sln- og .vbproj-filerne kan være nyttige til fejlsøgning af vanskelige problemer. Der er ingen skade i at se på dem, og disse filer fortæller dig, hvad der er virkelig foregår i din kode.
Som vi har set, kan du også redigere .sln- og .vbproj-filer direkte, selvom det normalt er en dårlig idé, medmindre der ikke er nogen anden måde at gøre det, du har brug for. Men nogle gange er der ingen anden måde. Hvis din computer f.eks. Kører i 64-bit-tilstand, er der ikke en måde at målrette mod en 32-bit CPU i VB.NET Express f.eks. For at være kompatibel med 32-bit Access Jet-databasemotoren. (Visual Studio giver en måde i de andre versioner), men du kan tilføje følgende:
Til elementerne