Întregul subiect al proiectelor, soluțiilor și fișierelor și instrumentelor care le controlează este ceva care este rareori explicat.
Aruncarea mâncării
Unul dintre marile avantaje ale drumului Microsoft a conceput soluții și proiecte este acela că un proiect sau o soluție este de sine stătător. Un director de soluții și conținutul acestuia pot fi mutate, copiate sau șterse în Windows Explorer. O întreagă echipă de programatori pot partaja un singur fișier soluție (.sln); un set întreg de proiecte pot face parte din aceeași soluție, iar setările și opțiunile din acel fișier .sln se pot aplica tuturor proiectelor din el. O singură soluție poate fi deschisă simultan în Visual Studio, dar o mulțime de proiecte pot fi în această soluție. Proiectele pot fi chiar în diferite limbi.
Puteți înțelege mai bine ceea ce este o soluție prin crearea câtorva și uitarea rezultatului. O „soluție goală” are ca rezultat un singur folder cu doar două fișiere: containerul soluției și opțiunile utilizatorului soluției. Dacă utilizați numele implicit, veți vedea:
Adăugați confidențialitate
Motivul principal pentru care puteți crea o soluție goală este de a permite crearea independentă a fișierelor de proiect și includerea în soluție. În sistemele mari, complexe, pe lângă faptul că fac parte din mai multe soluții, proiectele pot fi chiar cuibărite în ierarhii.
Fișierul containerului de soluții, interesant, este unul dintre puținele fișiere de configurare text care nu se află XML. O soluție necompletată conține aceste afirmații:
La fel de bine ar putea fi XML... este organizat la fel ca XML, dar fără sintaxa XML. Întrucât acesta este doar un fișier text, este posibil să-l editați într-un editor de text precum Notepad. De exemplu, puteți modifica HideSolutionNode = FALSE în TRUE și soluția nu va mai fi afișată în Exploratorul de soluții. (Numele din Visual Studio se schimbă și în „Project Explorer”.) Este bine să experimentați lucruri de genul acesta, atât timp cât lucrați la un proiect strict experimental. Nu ar trebui niciodată să schimbați fișierele de configurare manual pentru un sistem real decât dacă știți exact ce faceți, dar este destul de comun în mediile avansate să actualizați fișierul .sln direct și nu prin Visual Studio.
Fișierul .suo este ascuns și este un fișier binar, deci nu poate fi editat ca fișierul .sln. În mod normal, veți modifica acest fișier doar utilizând opțiunile de meniu din Visual Studio. Mergând în complexitate, consultați o aplicație Windows Forms. Chiar dacă aceasta ar putea fi cea mai elementară aplicație, există mai multe fișiere.
În plus față de un fișier .sln, șablonul de aplicație Windows Forms creează automat și un fișier .vbproj. Deși fișierele .sln și .vbproj sunt adesea utile, este posibil să observați că nu sunt afișate în fereastra Exploratorului de soluții Visual Studio, chiar și cu butonul „Afișați toate fișierele”. Dacă trebuie să lucrați direct cu aceste fișiere, trebuie să o faceți în afara Visual Studio.
Nu toate aplicațiile au nevoie de un fișier .vbproj. De exemplu, dacă selectați „Site Web nou” în Visual Studio, nu va fi creat fișier .vbproj. Deschideți folderul de nivel superior în Windows pentru aplicația Windows Forms și veți vedea cele patru fișiere pe care Visual Studio nu le arată. ssuming din nou numele implicit, acestea sunt: fișierele .sln și .vbproj pot fi utile pentru depanarea problemelor dificile. Nu este rău să le privești și aceste fișiere îți spun ce este într-adevăr continuând în codul tău.
După cum am văzut, puteți edita fișierele .sln și .vbproj direct, deși de obicei este o idee proastă, dacă nu există altă modalitate de a face ceea ce aveți nevoie. Dar uneori, nu există altă cale. De exemplu, dacă computerul rulează în modul pe 64 de biți, nu există o modalitate de a viza un procesor de 32 de biți VB.NET Express, de exemplu, pentru a fi compatibil cu motorul bazei de date Access Jet pe 32 de biți. (Visual Studio oferă o modalitate în celelalte versiuni), dar puteți adăuga următoarele:
La elemente