Menyiapkan folder paket nuget umum untuk semua solusi ketika beberapa proyek disertakan dalam beberapa solusi

141

Saya telah menggunakan NuGet untuk mengambil paket dari sumber paket eksternal dan internal, yang sangat nyaman. Tetapi saya telah menyadari bahwa paket secara default disimpan per solusi, yang sangat membuat frustrasi ketika beberapa proyek dengan referensi NuGet disertakan dalam beberapa solusi. Kemudian referensi diubah ke folder paket solusi lain yang mungkin sebenarnya tidak tersedia untuk pengembang atau mesin build lain.

Saya telah melihat bahwa ada cara untuk menunjukkan lokasi paket umum (mungkin di tingkat akar proyek, kami menggunakan kontrol sumber TFS) dengan rilis 2.1 dari NuGet, lihat catatan rilis . Saya menggunakan NuGet v2.7

Tetapi saya telah mencoba menambahkan file nuget.config tanpa melihat efek apa pun dari ini. Paket masih disimpan di folder solusi. Apakah ada yang saya lewatkan? Tampaknya ada struktur berbeda dari node xml untuk ditambahkan ke file nuget.config, tergantung pada siapa yang menjawab pertanyaan itu: Schwarzie menyarankan pada utas Stackoverflow lain :

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

Catatan rilis untuk NuGet 2.1 (lihat tautan di atas) menyarankan format ini: 

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

Saya tidak tahu yang mana, atau salah satu, atau keduanya yang pada akhirnya akan berhasil. Saya telah mencoba keduanya di tingkat solusi. Dapatkah file nuget.config ditempatkan di tingkat akar proyek TFS, atau haruskah itu ada di direktori solusi? Tampaknya NuGet membaca dan menerapkan pengaturan dari file-file ini dalam urutan tertentu, mengapa masuk akal untuk menambahkannya di beberapa level, di mana file nuget.config pada level solusi akan menimpa file di level root proyek TFS. Bisakah ini diperjelas?

Apakah saya perlu menghapus semua paket yang diinstal sebelum referensi tersebut berfungsi? Saya akan senang jika seseorang dapat memberikan instruksi langkah demi langkah untuk berpindah dari penggunaan nuget khusus solusi ke folder paket umum di mana proyek yang termasuk dalam beberapa solusi dapat menemukan paket nuget yang mereka butuhkan.

nuget  nuget-package  solution 
— Mats Isaksson
sumber
3
Saya menduga bahwa jawaban singkat untuk pertanyaan Anda (tersembunyi dalam jawaban Vermis di bawah) adalah bahwa Anda kehilangan $di depan jalur relatif. Juga, jawaban atas pertanyaan Anda tentang file NuGet.Config ada di sini . Ini terlihat pertama di .nuget, maka dalam semua direktori induk, maka pada file 'global' di AppData Anda: maka berlaku mereka dalam rangka MUNDUR (apapun yang berarti).
— Benjol
Ini sepertinya sulit. Ada tool bernama Paket yang bisa menjadi solusi untuk masalah ini: fsprojects.github.io/Paket
— Tuomas Hietanen
Komentar terlambat. Hanya ingin menambahkan bahwa Visual Studio perlu di-restart jika Anda menjalankannya ketika Anda memulai perubahan ini, karena file nuget.config tampaknya dibaca selama startup VS. Juga, saya tidak punya masalah tanpa $, hanya saja jangan mulai dengan garis miring terbalik.
— MBWise

Jawaban:

149

Saya memiliki situasi serupa dengan sumber paket eksternal dan internal dengan proyek yang dirujuk di lebih dari satu solusi. Saya baru saja membuatnya berfungsi dengan salah satu basis kode kami hari ini dan tampaknya berfungsi dengan workstation pengembang dan server build kami. Proses di bawah ini memiliki skenario ini dalam pikiran (meskipun seharusnya tidak sulit untuk beradaptasi untuk memiliki folder paket umum di tempat lain).

  • Basis kode
    • Proyek A
    • Proyek B
    • Proyek C
    • Solusi
      • Solusi 1
      • Solusi 2
      • Solusi 3
      • Paket (ini adalah paket umum yang dibagikan oleh semua solusi)

Jawaban yang diperbarui pada NuGet 3.5.0.1484 dengan Visual Studio 2015 Pembaruan 3

Proses ini sekarang sedikit lebih mudah daripada ketika saya awalnya menangani ini dan berpikir sudah waktunya untuk memperbarui ini. Secara umum, prosesnya sama hanya dengan beberapa langkah. Hasilnya adalah proses yang memecahkan atau menyediakan hal-hal berikut:

  • Segala sesuatu yang perlu dilakukan untuk kontrol kode sumber terlihat dan dilacak dalam solusi
  • Menginstal paket baru atau memperbarui paket menggunakan Package Manager di Visual Studio akan menggunakan jalur repositori yang benar
  • Setelah konfigurasi awal, tidak ada peretasan file .csproj
  • Tidak ada modifikasi workstation pengembang (Kode siap dibangun saat check out)

Ada beberapa potensi kerugian yang harus diperhatikan (saya belum mengalaminya, YMMV). Lihat jawaban dan komentar Benol di bawah ini.

Tambahkan NuGet.Config

Anda akan ingin membuat file NuGet.Config di root folder \ Solutions \. Pastikan ini adalah file berenkode UTF-8 yang Anda buat, jika Anda tidak yakin bagaimana melakukannya, gunakan menu File-> New-> File di Visual Studio dan kemudian pilih template File XML. Tambahkan ke NuGet.Config berikut ini:

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

Untuk setelan repositoryPath, Anda bisa menentukan jalur absolut atau jalur relatif (disarankan) menggunakan $ token. Token $ didasarkan pada di mana NuGet.Config berada (Token $ sebenarnya relatif terhadap satu tingkat di bawah lokasi NuGet.Config). Jadi, jika saya memiliki \ Solutions \ NuGet.Config dan saya ingin \ Solutions \ Packages, saya perlu menentukan $ \ .. \ Packages sebagai nilainya.

Selanjutnya, Anda akan ingin menambahkan Folder Solusi ke solusi Anda yang disebut sesuatu seperti "NuGet" (Klik kanan pada solusi Anda, Tambah-> Folder Solusi Baru). Folder Solusi adalah folder virtual yang hanya ada di solusi Visual Studio dan tidak akan membuat folder sebenarnya di drive (dan Anda dapat mereferensikan file dari mana saja). Klik kanan pada folder solusi "NuGet" Anda dan kemudian Add-> Existing Item dan pilih \ Solutions \ NuGet.Config.

Alasan kami melakukan ini adalah agar terlihat dalam solusi dan akan membantu memastikannya berkomitmen dengan benar ke kontrol kode sumber Anda. Anda mungkin ingin melakukan langkah ini untuk setiap solusi dalam basis kode Anda yang berpartisipasi dengan proyek bersama Anda.

Dengan menempatkan file NuGet.Config di \ Solutions \ di atas file .sln mana pun, kami memanfaatkan fakta bahwa NuGet akan secara rekursif menavigasi ke atas struktur folder dari "direktori kerja saat ini" mencari file NuGet.Config untuk digunakan. "Direktori kerja saat ini" berarti beberapa hal yang berbeda di sini, yang pertama adalah jalur eksekusi NuGet.exe dan yang lainnya adalah lokasi file .sln.

Mengalihkan folder paket Anda

Pertama, saya sangat menyarankan Anda melalui setiap folder solusi Anda dan menghapus folder \ Paket \ yang ada (Anda harus menutup Visual Studio terlebih dahulu). Ini membuatnya lebih mudah untuk melihat di mana NuGet menempatkan folder \ Paket \ yang baru Anda konfigurasi dan memastikan bahwa setiap tautan ke folder \ Paket \ yang salah akan gagal dan kemudian dapat diperbaiki.

Buka solusi Anda di Visual Studio dan mulai Rebuild All. Abaikan semua kesalahan build yang akan Anda terima, ini diharapkan pada saat ini. Ini harus memulai fitur pemulihan paket NuGet pada awal proses pembuatan. Verifikasi bahwa folder \ Solutions \ Packages \ Anda telah dibuat di tempat yang Anda inginkan. Jika belum, tinjau konfigurasi Anda.

Sekarang, untuk setiap proyek dalam solusi Anda, Anda ingin:

  1. Klik kanan pada proyek dan pilih Unload Project
  2. Klik kanan pada proyek dan pilih Edit-xxx.csproj Anda
  3. Temukan referensi apa pun ke \ paket \ dan perbarui ke lokasi baru.
    • Sebagian besar akan menjadi referensi <HintPath>, tetapi tidak semuanya. Misalnya, WebGrease dan Microsoft.Bcl.Build akan memiliki pengaturan jalur terpisah yang perlu diperbarui.
  4. Simpan .csproj lalu klik kanan pada proyek dan pilih Reload Project

Setelah semua file .csproj Anda diperbarui, mulai Rebuild All lagi dan Anda seharusnya tidak lagi menemukan error build tentang referensi yang hilang. Pada titik ini Anda sudah selesai, dan sekarang NuGet telah dikonfigurasi untuk menggunakan folder Paket bersama.

Mulai NuGet 2.7.1 (2.7.40906.75) dengan VStudio 2012

Hal pertama yang perlu diingat adalah bahwa nuget.config tidak mengontrol semua pengaturan jalur dalam sistem paket nuget. Ini sangat membingungkan untuk dipikirkan. Secara khusus, masalahnya adalah bahwa msbuild dan Visual Studio (memanggil msbuild) tidak menggunakan jalur di nuget.config melainkan menimpanya di file nuget.t target.

Persiapan Lingkungan

Pertama, saya akan melalui folder solusi Anda dan menghapus semua \ paket \ folder yang ada. Ini akan membantu memastikan bahwa semua paket secara jelas dipasang ke folder yang benar dan membantu menemukan referensi jalur yang buruk di seluruh solusi Anda. Selanjutnya, saya akan memastikan Anda memiliki ekstensi Visual Studio nuget terbaru yang diinstal. Saya juga akan memastikan Anda memiliki nuget.exe terbaru yang diinstal ke setiap solusi. Buka prompt perintah dan masuk ke setiap folder $ (SolutionDir) \ .nuget \ dan jalankan perintah berikut:

nuget update -self

Mengatur jalur folder paket umum untuk NuGet

Buka setiap $ (SolutionDir) \ .nuget \ NuGet.Config dan tambahkan yang berikut ini ke dalam bagian <configuration>:

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

Catatan: Anda dapat menggunakan jalur absolut atau jalur relatif. Perlu diingat, jika Anda menggunakan path relatif dengan $ yang relatif satu tingkat di bawah lokasi NuGet.Config (yakin ini adalah bug).

Menetapkan jalur folder paket umum untuk MSBuild dan Visual Studio

Buka setiap $ (SolutionDir) \ .nuget \ NuGet.t target dan ubah bagian berikut (perhatikan bahwa untuk non-Windows ada bagian lain di bawahnya):

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
    <PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>

Perbarui PackageDir menjadi

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

Catatan: GetFullPath akan menyelesaikan jalur relatif kita menjadi jalur absolut.

Mengembalikan semua paket nuget ke folder umum

Buka prompt perintah dan buka setiap $ (SolutionDir) \ .nuget dan jalankan perintah berikut:

nuget restore ..\YourSolution.sln

Pada titik ini, Anda harus memiliki satu folder \ paket \ di lokasi umum Anda dan tidak ada dalam folder solusi mana pun. Jika tidak, maka verifikasi jalur Anda.

Memperbaiki referensi proyek

Buka setiap file .csproj di editor teks dan temukan referensi apa pun ke \ paket dan perbarui ke jalur yang benar. Sebagian besar akan menjadi referensi <HintPath>, tetapi tidak semuanya. Misalnya, WebGrease dan Microsoft.Bcl.Build akan memiliki pengaturan jalur terpisah yang perlu diperbarui.

Bangun solusi Anda

Buka solusi Anda di Visual Studio dan mulai build. Jika mengeluh tentang paket yang hilang yang perlu dipulihkan, jangan berasumsi bahwa paket tersebut hilang dan perlu dipulihkan (kesalahan bisa menyesatkan). Ini bisa menjadi jalur yang buruk di salah satu file .csproj Anda. Periksa dulu sebelum mengembalikan paket.

Punya kesalahan versi tentang paket yang hilang?

Jika Anda telah memverifikasi bahwa jalur di file .csproj Anda sudah benar, maka Anda memiliki dua opsi untuk dicoba. Jika ini adalah hasil dari memperbarui kode Anda dari kontrol kode sumber, maka Anda dapat mencoba memeriksa salinan bersih dan kemudian membangunnya. Ini berfungsi untuk salah satu pengembang kami dan saya pikir ada artefak di file .suo atau yang serupa. Opsi lainnya adalah memaksa pemulihan paket secara manual menggunakan baris perintah di folder .nuget dari solusi yang dimaksud:

nuget restore ..\YourSolution.sln
— Vermis
sumber
Terima kasih atas jawaban panjang untuk masalah panjang saya. Saya akan mencoba solusi ini dan menghubungi Anda kembali.
— Mats Isaksson
Apakah akan berhasil jika keduanya .sln dalam direktori yang sama? akankah mereka akhirnya berbagi direktori paket yang sama?
— tofutim
7
Saya pikir jawaban ini menunjukkan betapa kaku nuget itu. Harus membuat struktur yang rumit dan kaku untuk memungkinkan konsep sederhana seperti itu: - "berbagi kumpulan yang sama di antara solusi" adalah indikasi dari desain yang buruk dari semuanya.
— Mick
1
Apa yang juga berfungsi untuk memperbaiki HintPaths - setelah Anda memperbarui NuGet.config sesuai keinginan Anda, di konsol Package-Manager jalankan "Update-Package -reinstall". Ini akan menginstal ulang semua paket, memperbaiki jalur petunjuk mereka juga. Setelah ini - Anda mungkin memiliki beberapa relik tersisa (saya punya di beberapa proyek silverlight - impor target / bangunan "lama" masih ada)
— johannes.colmsee
1
@Vermis Jika saya mengatur folder paket nuget umum untuk semua solusi saya. apa dampaknya pada build Azure Devops saya?
— Pankaj Devrani
39

Alih-alih menetapkan lokasi paket umum untuk semua proyek, dimungkinkan juga untuk mengubah HintPath dalam proyek sebagai berikut:

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

Dalam kebanyakan kasus, dalam proyek bersama hanya akan ada beberapa paket, sehingga Anda dapat dengan mudah mengubahnya.

Saya pikir ini adalah solusi yang lebih baik, ketika Anda bercabang kode, saat mengatur repo umum, Anda harus mengubah jalur relatif, dalam solusi ini Anda tidak perlu melakukan ini.

— Adam Wyżgoł
sumber
2
Adam benar. Ini adalah solusi paling sederhana untuk masalah bodoh yang luar biasa.
— lapsus
1
Itu adalah solusi yang brilian. sederhana dan jelas yang tidak memerlukan pembangunan kembali struktur kode apa pun.
— RredCat
2
AFAIK $ (SolutionDir) hanya diatur ketika pembangunan dilakukan melalui VS. Jadi tidak ada bangunan secara langsung melalui msbuild.exe, kecuali Anda menyetel / p: SolutionDir = jalur
— Lars Nielsen
ini dapat diatur secara otomatis di sini% APPDATA% \ Roaming \ NuGet \ NuGet.Config
— Korayem
15
Ini berfungsi dengan baik sampai Anda memperbarui paket, dan menimpa HintPath dengan jalur relatif baru. Menjadi sangat membosankan dalam solusi besar dengan banyak paket. Tuhan melarang Anda harus menjalankan Update-Package -Reinstall ...
— gravidThoughts
22

Pengalaman saya mencoba ini dengan versi terbaru NuGet (2.7) dan VS2012:

  • Hapus folder .nuget (pada disk dan dalam solusi)
  • Letakkan file NuGet.Config di folder induk umum dari semua solusi
  • Hapus semua folder paket yang ada
  • Pergi melalui semua file csproj dan ubah HintPaths untuk menunjuk ke lokasi baru
  • Keuntungan

Dalam kasus saya, saya ingin memasukkan semua paket .packages, jadi NuGet.Config saya terlihat seperti di bawah ini.

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

Perhatikan bahwa ada beberapa hal 'aneh' yang dapat terjadi, tetapi menurut saya hal itu dapat diterima:

  • Jika Anda 'Memperbarui' sebuah paket dari satu solusi, itu akan segera menghapus versi yang lebih lama dari folder paket Anda (tidak dapat mengetahui apakah Anda memiliki solusi lain yang mengarah ke sana). Ini tidak terlalu mengganggu saya, karena solusi lain hanya akan pulih saat diperlukan.
  • Jika Anda mencoba menambahkan paket dari solusi klik kanan, jika paket sudah ada di solusi lain, ia akan melihat bahwa paket itu ada di sana dan menampilkan 'centang hijau' alih-alih tombol 'instal'. Saya biasanya menginstal dari klik kanan pada proyek, jadi ini tidak mengganggu saya sama sekali.

Penafian : Saya baru mencobanya hari ini, saya tidak memiliki pengalaman jangka panjang untuk mendukungnya!

— Benjol
sumber
4
Ini adalah yang cara yang direkomendasikan untuk melakukannya. Cara integrasi msbuild lama untuk melakukan pemulihan nuget dalam jawaban yang diterima adalah pita, dan saya dapat mengonfirmasi menempatkan NuGet.config di samping sln berfungsi untuk kita dengan Pemulihan Paket Otomatis. Menempatkannya di direktori induk umum, saya tidak dapat mengonfirmasi.
— 9swampy
1
Bagaimana cara meletakkan NuGet.Config di folder induk umum untuk semua solusi (di TFS) sehingga mereka bisa merujuk? Satu-satunya cara yang saya tahu adalah folder .nuget di bawah setiap solusi yang memiliki file nuget.config; dan jika "repositorypath value = .packages" maka itu membuat subfolder di bawah .nuget seperti: C: \ TFS \ Comp \ Ent \ SolABC \ .nuget \ .packages - ini tidak menyelesaikan proyek / solusi bersarang dengan cara yang bersih yang seharusnya juga berfungsi pada build TFS otomatis. Jawaban yang diterima memerlukan beberapa pekerjaan kode tangan, ditambah "nilai jalur repositori = $ \ .. \ .. \ .. \ Paket ini tidak berfungsi jika ada proyek bertingkat yang memiliki jalur relatif berbeda.
— hB0
2
Bekerja dengan Visual Studio 2015 dan Nuget 3.4.3
— Hüseyin Yağlı
Tidak hanya akan segera menghapus paket yang lebih lama, itu juga akan menimpa dan merusak HintPath yang Anda masukkan ke dalam file csproj. @ hB0 benar. Ini hanya berfungsi untuk solusi yang relatif sederhana. Setelah Anda masuk ke dalam struktur ruang kerja TFS yang kompleks dengan cabang, proyek bersama, dll. Itu gagal untuk menskalakan secara efisien.
— gravidThoughts
20

Saya memiliki NuGet versi 2.8.50926 dengan VS 2013. Anda tidak perlu menggunakan beberapa file nuget.config, atau menggunakan struktur direktori yang kompleks. Ubah saja file default yang ada di sini:

%APPDATA%\Roaming\NuGet\NuGet.Config

Ini konten file saya:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

Jadi semua paket masuk ke folder "C: \ Projects \ nugetpackages", di mana pun solusinya.

Dalam semua solusi Anda, hapus saja folder "paket" yang ada. Kemudian buat solusi Anda, dan NuGet akan secara otomatis mengembalikan paket yang hilang di direktori baru yang terpusat yang Anda tentukan.

— Matthieu
sumber
Sejauh ini, ini adalah solusi termudah dari semuanya dan pantas mendapatkan lebih banyak cinta!
— Korayem
2
hari ini memang solusi termudah tetapi ada satu hal yang hilang dalam jawaban Anda. Anda masih perlu berurusan dengan HintPath di file csproj dari setiap proyek. Mereka tidak akan secara otomatis ditargetkan ke jalur baru. Apakah saya benar?
— Emil
Memang, di beberapa proyek lama saya terkadang ada referensi ke folder paket "lama". Namun bagi saya semuanya bekerja dengan benar, jadi saya kira pengaturan global lebih diutamakan.
— Matthieu
untuk OSX, lihat docs.microsoft.com/en-us/nuget/consume-packages/… . Saya juga menyukai ide mklink di bawah ini.
— sgtz
3

Dari Visual Studio 2013 Update 4 dan Nugget Package Manager versi> 2.8.5 ...

Buat file nuget.config di root repositori.

isi file:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Ini akan menyebabkan bahwa semua paket akan masuk ke folder paket pada level file nuget.config Anda.

Sekarang Anda dapat menggunakan setiap konsol nuget .sln dengan perintah 'update-package -reinstall'

Jika Anda memiliki beberapa repositori pada tingkat yang sama dan apa yang akan dibagikan folder paket yang sama di atasnya, coba gunakan cara untuk naik satu folder. 

 <add key="repositoryPath" value="..\packages" />

Tapi cara ini Anda menyebabkan referensi paket nuget csproj menunjuk satu folder di luar jalur repositori Anda.

— Janusz Nowak
sumber
3

Saya telah membuat paket NuGet yang secara transparan mengubah semua referensi NuGet dalam sebuah proyek ke dalam format $ (SolutionDir) -relatif. Itu melakukannya menggunakan transformasi XSLT waktu-build, jadi Anda tidak perlu meretas file proyek Anda dengan tangan. Anda dapat memperbarui paket Anda dengan bebas, itu tidak akan merusak apa pun.

https://www.nuget.org/packages/NugetRelativeRefs

Atau jika Anda menggunakan Visual Studio 2015 Update 3, Anda dapat memigrasi referensi paket ke project.jsonformulir seperti yang dijelaskan di sini: https://oren.codes/2016/02/08/project-json-all-the-things

— Oleg Tarasov
sumber
Sayangnya, sepertinya Microsoft beralih dari project.json . Juga, saya suka paket nuget Anda. Beberapa waktu yang lalu saya menggunakan NuGetReferenceHintPathRewrite yang melakukan hal yang hampir sama tetapi dengan cara yang berbeda
— Andrey Borisko
2

Memperbarui pengalaman saya dengan nuget 2.8.3. Itu relatif sederhana. Semua lakukan adalah mengaktifkan pemulihan paket dari solusi klik kanan. Diedit NuGet.Config dan menambahkan baris ini:

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

Kemudian buat kembali solusinya, ia mengunduh semua paket ke folder yang saya inginkan dan memperbarui referensi secara otomatis. Saya melakukan hal yang sama untuk semua proyek saya yang lain, di mana hanya paket tambahan yang diunduh dan paket yang ada direferensikan. Oleh karena itu repositori paket umum untuk semua proyek yang telah ditetapkan.

Berikut adalah prosedur langkah demi langkah untuk mengaktifkan pemulihan paket.

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

— amarnath chatterjee
sumber
2

Cukup tautkan / paket ke lokasi bersama yang diinginkan. Maka proyek Anda tidak akan rusak untuk pengguna lain, yang tidak memiliki lokasi paket khusus.

Buka prompt perintah sebagai admin dan gunakan

mklink /prefix link_path Target_file/folder_path
— pengguna803469
sumber
2

Untuk solusi signifikan apa pun, jawaban di atas akan gagal. Sederhananya, struktur ruang kerja TFS yang kompleks dengan jalur relatif yang berbeda, percabangan, proyek bersama, dll. Membuat satu repositori pusat tidak mungkin.

Menggunakan ($ SolutionDir) adalah langkah ke arah yang benar, tetapi pengkodean tangan file csproj dengan ($ SolutionDir) akan menjadi sangat membosankan dalam basis kode dengan ratusan paket yang diperbarui secara berkala (setiap kali pembaruan terjadi, HintPath akan ditimpa dengan jalur relatif baru). Apa yang terjadi jika Anda harus menjalankan Update-Package -Reinstall.

Ada solusi hebat yang disebut NugetReferenceHintPathRewrite . Ini mengotomatiskan injeksi ($ SolutionDir) ke dalam HintPaths sebelum membangun (tanpa benar-benar mengubah file csproj). Saya membayangkan itu dapat dengan mudah dimasukkan ke dalam sistem build otomatis

— gravidThoughts
sumber
1

Ringkasan singkat bagi mereka di VS 2013 profesional dengan nuget Versi: 2.8.60318.667

Ini adalah cara Anda mengarahkan paket ke jalur yang terkait dengan folder .nuget:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

Misalnya, jika solusi Anda (file .sln) berada di C: \ Projects \ MySolution, saat Anda mengaktifkan pemulihan paket NuGet, folder .nuget akan dibuat seperti ini: C: \ Projects \ MySolution.nuget dan paket akan diunduh ke direktori seperti ini: C: \ Projects \ MySolution \ Dependencies

CATATAN: Untuk beberapa alasan (tidak diketahui), setiap kali saya memperbarui "repositoryPath", saya harus menutup dan membuka kembali solusi agar perubahan diterapkan

— Sudhanshu Mishra
sumber
Perhatikan bahwa ada garis miring yang hilang pada tag konfigurasi penutup.
— Moo
— HANiS
0

untuk mereka yang menggunakan paket sebagai manajer paket mereka, ada opsi auto-symlink untuk file dependensi Anda:

storage: symlink

btw: paket leverages nuget

referensi: https://fsprojects.github.io/Paket/dependencies-file.html

Jika Anda ingin memodifikasi sesedikit mungkin, Anda dapat membersihkan subdirektori secara berkala dengan skrip. yaitu. Perilaku default Nuget adalah menyalin file dari lokasi global ke folder paket lokal, jadi hapus file ini setelahnya.

— sgtz
sumber
0

Saya hanya menggunakan persimpangan NTFS untuk membuat semua folder paket langsung ke satu folder di atas akar repositori. Bekerja dengan baik. Tidak ada masalah dengan pemulihan paket paralel di berbagai solusi. Satu keuntungan dari ini adalah Anda tidak perlu mengonfigurasi ulang apa pun di kode sumber Anda, seperti ratusan jalur petunjuk relatif di file .csproj Anda. Ini 'hanya bekerja' dengan membiarkan sistem file menangani pengalihan dan simulasi folder paket tunggal.

Waspadai masalah 'git'. Meskipun 'status git' melalui baris perintah tidak menunjukkan perubahan tidak bertahap, saya perhatikan bahwa GitKraken melihat sambungan 'paket' sebagai file yang tidak diatur . Ia bahkan menunjukkan kesalahan seperti 'file adalah direktori' ketika Anda mengkliknya. GitKraken juga akan mencoba untuk menyimpan 'file' ini jika Anda melakukan rebase, menghancurkan junction, dan mengembalikannya sebagai file aktual yang berisi teks dengan path file asli. Perilaku yang sangat aneh. Mungkin bisa mengatasinya dengan memastikan file paket ditambahkan ke .gitignore Anda.

— Triynko
sumber
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.