Haruskah a .sln berkomitmen untuk kontrol sumber?


101

Apakah praktik terbaik untuk memasukkan file .sln ke kontrol sumber? Kapan tepat atau tidak tepat untuk melakukannya?

Pembaruan Ada beberapa poin bagus yang dibuat dalam jawaban. Terima kasih atas tanggapannya!


21
Saya yakin itu adalah file .SUO yang TIDAK Anda inginkan.
apandit

Sekadar catatan, saya percaya bahwa daftar Tugas (jika Anda menggunakannya) disimpan dalam file .SUO ... Jadi meskipun Anda mungkin tidak ingin memasukkannya ke kontrol sumber, Anda mungkin tidak ingin 'hanya menghapus' sebagai cruft asing.
Benjol

Jawaban:


69

Saya pikir jelas dari jawaban lain bahwa file solusi berguna dan harus dilakukan, bahkan jika tidak digunakan untuk build resmi. Mereka berguna untuk siapa saja yang menggunakan fitur Visual Studio seperti Go To Definition / Declaration.

Secara default, mereka tidak berisi jalur absolut atau artefak khusus mesin lainnya. (Sayangnya, beberapa alat tambahan tidak memelihara properti ini dengan baik, misalnya, AMD CodeAnalyst.) Jika Anda berhati-hati menggunakan jalur relatif dalam file proyek Anda (baik C ++ dan C #), mereka akan menjadi mesin-independen terlalu.

Mungkin pertanyaan yang lebih berguna adalah: file apa yang harus Anda kecualikan? Berikut konten file .gitignore saya untuk proyek VS 2008 saya:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(Entri terakhir hanya untuk profiler AMD CodeAnalyst.)

Untuk VS 2010, Anda juga harus mengecualikan yang berikut ini:

ipch/
*.sdf
*.opensdf

2
Saya juga memiliki aturan pengabaian untuk hasil tes Unit. Beberapa orang mungkin memeriksanya tetapi saya tidak suka yang berantakan
Matthew Whited

9
+1 - Saya pribadi juga tidak melakukan apa pun yang dibuat, jadi bin / dan obj /
Steven Evers

Saya hanya melakukan file .sln yang berisi lebih dari 1 proyek
Justin

2
di sini adalah subversi saya Pola abaikan global: * .vsmdi * .suo * / [Bb] di [Bb] di * / obj obj TestResults *. [Uu] ser * Thumbs.db * Web.Publish.xml * WebApplication.Publish. xml * Web.log
Merritt

Berikut adalah file .gitignore yang umum dibagikan yang menyertakan file sementara, hasil build, dan file yang dibuat oleh add-on Visual Studio populer.
Lauren Van Sloun

58

Ya - Saya pikir itu selalu tepat. Pengaturan khusus pengguna ada di file lain.


3
Pasti .sln memiliki referensi ke file .prj (proyek)
dplante

20

Ya, Anda harus melakukan ini. File solusi hanya berisi informasi tentang keseluruhan struktur solusi Anda. Informasi bersifat global untuk solusi dan kemungkinan umum bagi semua pengembang dalam proyek Anda.

Itu tidak berisi pengaturan khusus pengguna.


13

Anda pasti harus memilikinya. Di samping alasan yang disebutkan orang lain, diperlukan satu langkah untuk membangun keseluruhan proyek.


8

Saya biasanya setuju bahwa file solusi harus diperiksa, namun, di perusahaan tempat saya bekerja, kami telah melakukan sesuatu yang berbeda. Kami memiliki repositori yang cukup besar dan pengembang mengerjakan berbagai bagian sistem dari waktu ke waktu. Untuk mendukung cara kami bekerja, kami akan memiliki satu file solusi besar atau beberapa yang lebih kecil. Keduanya memiliki beberapa kekurangan dan membutuhkan pekerjaan manual di pihak pengembang. Untuk menghindari ini, kami telah membuat plug-in yang menangani semua itu.

Plug-in memungkinkan setiap pengembang memeriksa subset dari pohon sumber untuk dikerjakan hanya dengan memilih proyek yang relevan dari repositori. Plugin kemudian menghasilkan file solusi dan mengubah file proyek dengan cepat untuk solusi yang diberikan. Ini juga menangani referensi. Dengan kata lain, yang harus dilakukan pengembang adalah memilih proyek yang sesuai dan kemudian file yang diperlukan dibuat / dimodifikasi. Ini juga memungkinkan kami menyesuaikan berbagai pengaturan lain untuk memastikan standar perusahaan.

Selain itu, kami menggunakan plugin untuk mendukung berbagai kebijakan check-in, yang biasanya mencegah pengguna mengirimkan kode yang salah / tidak sesuai ke repositori.


Kedengarannya seperti ini mungkin jawaban untuk salah satu pertanyaan saya yang sudah lama tidak terjawab ( stackoverflow.com/questions/1490728/… ), apakah ada peluang untuk mendapatkan salinan plugin ini?
Benjol

@ Benjol: Maaf, tidak, ini adalah alat internal. Selain fitur-fitur di atas, ia juga terintegrasi dengan sejumlah sistem internal lainnya, jadi sangat spesifik dengan cara kami menjalankan sesuatu. Jika Anda hanya membutuhkan solusi / bagian proyek dari hal-hal itu tidak sulit untuk diterapkan.
Brian Rasmussen

OK, hanya satu hal, dalam 'solusi besar' Anda apakah Anda memiliki referensi proyek atau referensi file? Dan jika pengembang menambahkan referensi baru ke file / proyek, apakah plugin melakukan konversi yang sesuai kembali sebelum check in? Dan bagaimana Anda menangani dependensi yang belum dipilih pengembang untuk diselesaikan?
Benjol

8

Ya, hal-hal yang harus Anda lakukan adalah:

  • solusi (* .sln),
  • file proyek,
  • semua file sumber,
  • file konfigurasi aplikasi
  • membangun skrip

Hal-hal yang tidak boleh Anda lakukan adalah:

  • file opsi pengguna solusi (.suo),
  • membangun file yang dihasilkan (misalnya menggunakan skrip build) [Edit:] - hanya jika semua skrip dan alat build yang diperlukan tersedia di bawah kontrol versi (untuk memastikan build itu otentik dalam riwayat cvs)

Mengenai file yang dibuat secara otomatis lainnya, ada utas terpisah .


1
Saya harus tidak setuju dengan "file yang dibuat secara otomatis."
Mehrdad Afshari

@Mehrdad, apakah menurut Anda file Intelisense harus dikomit juga?
Edison Gustavo Muenz

1
@ Edison: Tidak. Saya mengacu pada file sumber yang dibuat secara otomatis seperti LINQ ke konteks data SQL, misalnya.
Mehrdad Afshari

2
Bukankah file Formname.Designer.cs dianggap dibuat secara otomatis?
jasonh

1
Yang saya maksud adalah file yang dihasilkan selama waktu pembuatan. Saya sering menemukan ini - seseorang melakukan file yang dibuat secara otomatis, dan kemudian SVN melaporkan perubahan hanya karena beberapa komentar diubah.
Groo

5

Ya, ini harus menjadi bagian dari kendali sumber. Kapan pun Anda menambahkan / menghapus proyek dari aplikasi Anda, .sln akan diperbarui dan akan lebih baik jika Anda memilikinya di bawah kendali sumber. Ini akan memungkinkan Anda untuk menarik kembali versi kode aplikasi 2 Anda dan langsung melakukan build (jika diperlukan).


5

Di sebagian besar situasi, sebaiknya komit file .sln ke kontrol sumber.

Jika file .sln Anda dibuat oleh alat lain (seperti CMake), mungkin tidak tepat untuk menempatkannya ke dalam kontrol sumber.


4

Ya, Anda selalu ingin menyertakan file .sln, ini menyertakan tautan ke semua proyek yang ada dalam solusi.


2

Kami melakukannya karena itu membuat semuanya tetap sinkron. Semua proyek yang diperlukan ditempatkan bersama, dan tidak ada yang perlu khawatir kehilangan satu pun. Server build kami (Ant Hill Pro) juga menggunakan sln untuk menentukan project mana yang akan dibuat untuk rilis.


2

Kami biasanya meletakkan semua file solusi kami di direktori solusi. Dengan cara ini kami memisahkan solusi dari kode sedikit, dan lebih mudah untuk memilih proyek yang perlu saya kerjakan.


1

Satu-satunya kasus di mana Anda bahkan akan mempertimbangkan untuk tidak menyimpannya dalam kontrol sumber adalah jika Anda memiliki solusi besar dengan banyak proyek yang berada dalam kendali sumber, dan Anda ingin membuat solusi kecil dengan beberapa proyek dari solusi utama untuk beberapa persyaratan transien pribadi.


1

Ya - Semua yang digunakan untuk menghasilkan produk Anda harus berada dalam kendali sumber.


1

Kami menyimpan atau menyelesaikan file dalam Kontrol Versi TFS. Tetapi karena atau solusi utama sangat besar, sebagian besar pengembang memiliki solusi pribadi yang hanya berisi apa yang mereka butuhkan. File solusi utama sebagian besar digunakan oleh server build.


0

.slns adalah satu-satunya hal yang tidak bermasalah di tfs!


1
Itu lucu ... SLN adalah satu-satunya file yang harus saya perbaiki ... tetapi masalah ini disebabkan oleh devs yang tidak berhati-hati dengan penggabungan.
Matthew Whited
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.