Apa praktik terbaik untuk “Menyalin Lokal” dan dengan referensi proyek?


154

Saya memiliki file solusi c # besar (~ 100 proyek), dan saya mencoba untuk meningkatkan waktu pembuatan. Saya pikir "Copy Local" boros dalam banyak kasus bagi kami, tetapi saya bertanya-tanya tentang praktik terbaik.

Dalam .sln, kami memiliki aplikasi A tergantung pada rakitan B yang tergantung pada rakitan C. Dalam kasus kami, ada lusinan "B" dan beberapa "C". Karena ini semua termasuk dalam .sln, kami menggunakan referensi proyek. Semua majelis saat ini membangun $ (SolutionDir) / Debug (atau Rilis).

Secara default, Visual Studio menandai referensi proyek ini sebagai "Salin Lokal", yang menghasilkan setiap "C" disalin ke $ (SolutionDir) / Debug sekali untuk setiap "B" yang membangun. Ini sepertinya boros. Apa yang salah jika saya mematikan "Salin Lokal"? Apa yang dilakukan orang lain dengan sistem besar?

MENGIKUTI:

Banyak tanggapan menyarankan untuk memecah bangunan menjadi file .sln yang lebih kecil ... Pada contoh di atas, saya akan membangun kelas dasar "C" terlebih dahulu, diikuti oleh sebagian besar modul "B", dan kemudian beberapa aplikasi, " SEBUAH". Dalam model ini, saya perlu memiliki referensi non-proyek untuk C dari B. Masalah yang saya temui adalah bahwa "Debug" atau "Release" dimasukkan ke jalur petunjuk dan saya akhirnya membangun build rilis saya dengan "B" terhadap debug membangun "C".

Bagi Anda yang membagi bangunan menjadi beberapa file .sln, bagaimana Anda mengelola masalah ini?


9
Anda dapat membuat Referensi Petunjuk Anda direktori Debug atau Rilis dengan mengedit file proyek secara langsung. Gunakan $ (Konfigurasi) sebagai pengganti Debug atau Release. Misalnya, <HintPath> .. \ output \ $ (Configuration) \ test.dll </HintPath> Ini adalah rasa sakit ketika Anda memiliki banyak referensi (walaupun seharusnya tidak sulit bagi seseorang untuk menulis add-in ke kelola ini).
ultravelocity

4
Apakah 'Salin Lokal' di Visual Studio sama dengan <Private>True</Private>di csproj?
Kolonel Panic

Tetapi memecah .slnmenjadi yang lebih kecil mematahkan perhitungan interdependensi automagic VS <ProjectReference/>s. Saya telah pindah dari beberapa yang lebih kecil .slnmenjadi satu yang besar .slnsendiri hanya karena VS menyebabkan lebih sedikit masalah dengan cara itu ... Jadi, mungkin tindak lanjutnya dengan mengasumsikan solusi yang belum tentu terbaik untuk pertanyaan awal? ;-)
binki

Hanya karena penasaran. Mengapa mempersulit dan memiliki 100+ proyek di tempat pertama? Apakah ini desain yang buruk atau apa?
bermanfaatBee

@ColonelPanic Ya. Setidaknya itu adalah hal yang berubah pada disk ketika saya mengubah sakelar di GUI.
Zero3

Jawaban:


85

Dalam proyek sebelumnya saya bekerja dengan satu solusi besar dengan referensi proyek dan menabrak masalah kinerja juga. Solusinya tiga kali lipat:

  1. Selalu atur properti Salin Lokal ke false dan tegakkan ini melalui langkah msbuild khusus

  2. Atur direktori output untuk setiap proyek ke direktori yang sama (lebih disukai relatif ke $ (SolutionDir)

  3. Target cs default yang dikirimkan dengan kerangka kerja menghitung set referensi yang akan disalin ke direktori keluaran proyek yang saat ini sedang dibangun. Karena ini memerlukan penghitungan penutupan transitif di bawah hubungan 'Referensi', ini bisa menjadi SANGAT mahal. Solusi saya untuk ini adalah mendefinisikan kembali GetCopyToOutputDirectoryItemstarget dalam file target umum (mis. Common.targets) Yang diimpor di setiap proyek setelah impor Microsoft.CSharp.targets. Menghasilkan setiap file proyek terlihat seperti berikut:

    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        ... snip ...
      </ItemGroup>
      <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
      <Import Project="[relative path to Common.targets]" />
      <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
           Other similar extension points exist, see Microsoft.Common.targets.
      <Target Name="BeforeBuild">
      </Target>
      <Target Name="AfterBuild">
      </Target>
      -->
    </Project>
    

Ini mengurangi waktu build kami pada waktu tertentu dari beberapa jam (sebagian besar karena kendala memori), menjadi beberapa menit.

The didefinisikan ulang GetCopyToOutputDirectoryItemsdapat dibuat dengan menyalin garis 2,438-2,450 dan 2,474-2,524 dari C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targetsdalam Common.targets.

Untuk kelengkapan definisi target yang dihasilkan kemudian menjadi:

<!-- This is a modified version of the Microsoft.Common.targets
     version of this target it does not include transitively
     referenced projects. Since this leads to enormous memory
     consumption and is not needed since we use the single
     output directory strategy.
============================================================
                    GetCopyToOutputDirectoryItems

Get all project items that may need to be transferred to the
output directory.
============================================================ -->
<Target
    Name="GetCopyToOutputDirectoryItems"
    Outputs="@(AllItemsFullPathWithTargetPath)"
    DependsOnTargets="AssignTargetPaths;_SplitProjectReferencesByFileExistence">

    <!-- Get items from this project last so that they will be copied last. -->
    <CreateItem
        Include="@(ContentWithTargetPath->'%(FullPath)')"
        Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(_EmbeddedResourceWithTargetPath->'%(FullPath)')"
        Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(Compile->'%(FullPath)')"
        Condition="'%(Compile.CopyToOutputDirectory)'=='Always' or '%(Compile.CopyToOutputDirectory)'=='PreserveNewest'">
        <Output TaskParameter="Include" ItemName="_CompileItemsToCopy"/>
    </CreateItem>
    <AssignTargetPath Files="@(_CompileItemsToCopy)" RootFolder="$(MSBuildProjectDirectory)">
        <Output TaskParameter="AssignedFiles" ItemName="_CompileItemsToCopyWithTargetPath" />
    </AssignTargetPath>
    <CreateItem Include="@(_CompileItemsToCopyWithTargetPath)">
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(_NoneWithTargetPath->'%(FullPath)')"
        Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>
</Target>

Dengan solusi ini di tempat saya menemukan itu bisa diterapkan untuk memiliki sebanyak> 120 proyek dalam satu solusi, ini memiliki manfaat utama bahwa urutan pembangunan proyek masih dapat ditentukan oleh VS daripada melakukan itu dengan tangan dengan membagi solusi Anda .


Bisakah Anda menggambarkan perubahan yang Anda buat dan mengapa? Bola mata saya terlalu lelah setelah seharian berkode untuk mencoba merekayasa balik sendiri :)
Charlie Flowers

Bagaimana kalau mencoba menyalin & menempel ini lagi - BEGITU kacau seperti 99% dari tag.
ZXX

@Charlie Flowers, @ZXX mengedit teks menjadi deskripsi tidak bisa mendapatkan tata letak xml dengan baik.
Bas Bossink

1
Dari Microsoft.Common.targets: GetCopyToOutputDirectoryItems Dapatkan semua item proyek yang mungkin perlu ditransfer ke direktori output. Ini termasuk barang-barang bagasi dari proyek yang direferensikan secara transitif. Tampaknya target ini menghitung penutupan transitif penuh atas item konten untuk semua proyek yang dirujuk; Namun bukan itu masalahnya.
Brans Ds

2
Itu hanya mengumpulkan item konten dari anak-anak langsung dan bukan anak-anak anak-anak. Alasan ini terjadi adalah daftar ProjectReferenceWithConfiguration yang dikonsumsi oleh _SplitProjectReferencesByFileExistence hanya diisi dalam proyek saat ini dan kosong pada anak-anak. Daftar kosong menyebabkan _MSBuildProjectReferenceExistent menjadi kosong dan mengakhiri rekursi. Jadi sepertinya tidak berguna.
Brans Ds

32

Saya sarankan Anda membaca artikel Patric Smacchia tentang hal itu:

Proyek CC.Net VS bergantung pada opsi rakitan salinan lokal yang disetel ke true. [...] Tidak hanya ini meningkatkan waktu kompilasi secara signifikan (x3 dalam kasus NUnit), tetapi juga mengacaukan lingkungan kerja Anda. Yang terakhir namun tidak kalah pentingnya, melakukan hal itu memperkenalkan risiko untuk membuat versi masalah potensial. Btw, NDepend akan memancarkan peringatan jika ditemukan 2 majelis di 2 direktori berbeda dengan nama yang sama, tetapi bukan konten atau versi yang sama.

Yang benar untuk dilakukan adalah mendefinisikan 2 direktori $ RootDir $ \ bin \ Debug dan $ RootDir $ \ bin \ Lepaskan, dan konfigurasikan proyek VisualStudio Anda untuk mengeluarkan rakitan di direktori ini. Semua referensi proyek harus merujuk rakitan di direktori Debug.

Anda juga dapat membaca artikel ini untuk membantu Anda mengurangi jumlah proyek Anda dan meningkatkan waktu kompilasi Anda.


1
Saya berharap saya bisa merekomendasikan praktik Smacchia dengan lebih dari satu upvote! Mengurangi jumlah proyek adalah kuncinya, bukan memisahkan solusi.
Anthony Mastrean

23

Saya sarankan memiliki salinan local = false untuk hampir semua proyek kecuali yang ada di atas pohon dependensi. Dan untuk semua referensi yang ada di atas set copy local = true. Saya melihat banyak orang menyarankan berbagi direktori keluaran; Saya pikir ini adalah ide yang mengerikan berdasarkan pengalaman. Jika proyek startup Anda menyimpan referensi ke dll yang mana proyek lain memegang referensi untuk Anda pada suatu saat akan mengalami pelanggaran akses \ berbagi bahkan jika salinan lokal = salah pada semuanya dan bangunan Anda akan gagal. Masalah ini sangat menyebalkan dan sulit dilacak. Saya benar-benar menyarankan menjauh dari direktori keluaran beling dan bukannya memiliki proyek di bagian atas rantai ketergantungan menulis majelis yang diperlukan ke folder yang sesuai. Jika Anda tidak memiliki proyek di "atas," maka saya akan menyarankan salinan post-build untuk mendapatkan semuanya di tempat yang tepat. Juga, saya akan mencoba dan mengingat kemudahan debugging. Setiap proyek exe saya masih meninggalkan copy local = true sehingga pengalaman debug F5 akan bekerja.


2
Saya punya ide yang sama dan berharap menemukan orang lain yang berpikiran sama di sini; namun, saya ingin tahu mengapa posting ini tidak memiliki lebih banyak upvotes. Orang yang tidak setuju: mengapa Anda tidak setuju?
bwerks

Tidak ada yang tidak dapat terjadi kecuali proyek yang sama sedang membangun dua kali, mengapa itu akan ditimpa pelanggaran \ access \ sharing jika dibangun sekali dan tidak menyalin file apa pun?
paulm

Ini. Jika alur kerja pengembangan membutuhkan pembangunan satu proyek SLN, sementara proyek lain-exectutable dari solusi sedang berjalan, memiliki semua yang ada di direktori output yang sama akan berantakan. Jauh lebih baik untuk memisahkan folder keluaran yang dapat dieksekusi dalam kasus ini.
Martin Ba

10

Anda benar. CopyLocal benar-benar akan membunuh waktu membangun Anda. Jika Anda memiliki struktur kode sumber yang besar maka Anda harus menonaktifkan CopyLocal. Sayangnya itu tidak semudah menonaktifkannya dengan benar. Saya telah menjawab pertanyaan ini tentang menonaktifkan CopyLocal di Bagaimana cara mengganti pengaturan CopyLocal (Pribadi) untuk referensi di .NET dari MSBUILD . Saksikan berikut ini. Serta praktik terbaik untuk solusi besar di Visual Studio (2008).

Berikut ini beberapa info lebih lanjut tentang CopyLocal seperti yang saya lihat.

CopyLocal benar-benar diimplementasikan untuk mendukung debugging lokal. Ketika Anda menyiapkan aplikasi untuk pengemasan dan penyebaran, Anda harus membangun proyek Anda ke folder keluaran yang sama dan pastikan Anda memiliki semua referensi yang Anda butuhkan di sana.

Saya telah menulis tentang bagaimana menangani membangun pohon sumber besar dalam artikel MSBuild: Praktik Terbaik Untuk Membuat Bangunan yang Andal, Bagian 2 .


8

Menurut pendapat saya, memiliki solusi dengan 100 proyek adalah kesalahan besar. Anda mungkin dapat membagi solusi Anda dalam unit logis kecil yang valid, sehingga menyederhanakan pemeliharaan dan pembuatan.


1
Bruno, silakan lihat pertanyaan tindak lanjut saya di atas - jika kita membobol file .sln yang lebih kecil, bagaimana Anda mengelola aspek Debug vs Rilis yang kemudian dimasukkan ke jalur petunjuk referensi saya?
Dave Moore

1
Saya setuju dengan poin ini, solusi yang saya kerjakan memiliki ~ 100 proyek, hanya sedikit yang memiliki lebih dari 3 kelas, waktu pembuatannya mengejutkan, dan sebagai hasilnya pendahulu saya membagi solusi menjadi 3 yang benar-benar rusak. semua referensi dan refactoring. Semuanya bisa masuk dalam beberapa proyek yang akan dibangun dalam hitungan detik!
Jon M

Dave, pertanyaan bagus. Di mana saya bekerja, kami telah membangun skrip yang melakukan hal-hal seperti membangun dependensi untuk solusi yang diberikan dan menempatkan binari di suatu tempat di mana solusi yang dimaksud bisa mendapatkannya. Skrip ini dipastikan untuk debug dan rilis build. Downside adalah waktu ekstra di muka untuk membangun skrip tersebut, tetapi mereka dapat digunakan kembali di seluruh aplikasi. Solusi ini telah bekerja dengan baik menurut standar saya.
jyoungdev

7

Saya terkejut tidak ada yang disebutkan menggunakan hardlink. Alih-alih menyalin file, itu membuat hardlink ke file asli. Ini menghemat ruang disk dan juga mempercepat pembangunan. Ini dapat diaktifkan pada baris perintah dengan properti berikut:

/ p: CreateHardLinksForAdditionalFilesIfPossible = true; CreateHardLinksForCopyAdditionalFilesIfPossible = true; CreateHardLinksForCopyFilesToOutputDirectoryIfPossible = true; CreateHardLinksForCopyLocalIfPemungkinanBertarungPelanggan = truePemungkinanBertarungungDapatMungkin = true;

Anda juga dapat menambahkan ini ke file impor pusat sehingga semua proyek Anda juga bisa mendapatkan manfaat ini.


5

Jika Anda mendapatkan struktur dependensi yang ditentukan melalui referensi proyek atau melalui dependensi tingkat solusi, aman untuk mengaktifkan "Salin Lokal" Saya bahkan akan mengatakan bahwa itu adalah praktik terbaik untuk dilakukan, karena itu akan memungkinkan Anda menggunakan MSBuild 3.5 untuk menjalankan build Anda secara paralel ( via / maxcpucount) tanpa proses berbeda yang saling berujung ketika mencoba menyalin rujukan yang direferensikan.


4

"praktik terbaik" kami adalah menghindari solusi dengan banyak proyek. Kami memiliki direktori bernama "matrix" dengan versi rakitan saat ini, dan semua referensi berasal dari direktori ini. Jika Anda mengubah beberapa proyek dan Anda dapat mengatakan "sekarang perubahannya selesai" Anda dapat menyalin perakitan ke direktori "matriks". Jadi semua proyek yang bergantung pada perakitan ini akan memiliki versi saat ini (= terbaru).

Jika Anda memiliki beberapa proyek dalam penyelesaian, proses pembuatannya jauh lebih cepat.

Anda dapat mengotomatiskan langkah "salin rakitan ke direktori matriks" menggunakan makro studio visual atau dengan "menu -> alat -> alat eksternal ...".


3

Anda tidak perlu mengubah nilai CopyLocal. Yang perlu Anda lakukan adalah menetapkan $ umum (OutputPath) untuk semua proyek dalam solusi dan $ ditetapkan sebelumnya (UseCommonOutputDirectory) menjadi true. Lihat ini: http://blogs.msdn.com/b/kirillosenkov/archive/2015/04/04/using-a-common-intermediate-and-output-directory-for-your-solution.aspx


Saya tidak yakin ini tersedia kembali pada tahun 2009, tetapi tampaknya berfungsi dengan baik pada tahun 2015. Terima kasih!
Dave Moore

2

Set CopyLocal = false akan mengurangi waktu pembuatan, tetapi dapat menyebabkan masalah yang berbeda selama penerapan.

Ada banyak skenario, ketika Anda perlu memiliki Copy Local 'kiri ke True, misalnya

  • Proyek tingkat atas,
  • Dependensi tingkat kedua,
  • DLL disebut dengan refleksi

Masalah yang mungkin dijelaskan dalam pertanyaan SO
" Kapan salinan-lokal disetel ke true dan kapan tidak? ",
" Pesan kesalahan 'Tidak dapat memuat satu atau lebih dari jenis yang diminta. Ambil properti LoaderExceptions untuk informasi lebih lanjut.' "
Dan   aaron-stainback 's jawaban  untuk pertanyaan ini.

Pengalaman saya dengan pengaturan CopyLocal = false TIDAK berhasil. Lihat posting blog saya "JANGAN Ubah referensi proyek" Salin Lokal "ke false, kecuali pahami selanjutnya."

Waktu untuk mengatasi masalah kelebihan manfaat pengaturan copyLocal = false.


Pengaturan CopyLocal=Falsepasti akan menyebabkan beberapa masalah, tetapi ada solusi untuk itu. Juga, Anda harus memperbaiki format blog Anda, itu hampir tidak dapat dibaca, dan mengatakan di sana bahwa "Saya telah diperingatkan oleh <konsultan acak> dari <perusahaan acak> tentang kemungkinan kesalahan selama penyebaran" bukan argumen. Anda perlu berkembang.
Suzanne Dupéron

@ GeorgesDupéron, Waktu untuk mengatasi masalah kelebihan manfaat pengaturan copyLocal = false. Referensi ke konsultan bukan argumen, tetapi kredit, dan blog saya menjelaskan apa masalahnya. Terima kasih atas tanggapan Anda. memformat, saya akan memperbaikinya.
Michael Freidgeim

1

Saya cenderung membangun ke direktori umum (misalnya .. \ bin), jadi saya bisa membuat solusi pengujian kecil.


1

Anda dapat mencoba menggunakan folder tempat semua rakitan yang dibagikan di antara proyek akan disalin, lalu buat variabel lingkungan DEVPATH dan atur

<developmentMode developerInstallation="true" />

dalam file machine.config pada setiap workstation pengembang. Satu-satunya hal yang perlu Anda lakukan adalah menyalin versi baru di folder Anda di mana DEVPATH mengarahkan poin.

Juga bagi solusi Anda menjadi beberapa solusi yang lebih kecil jika memungkinkan.


Menarik ... Bagaimana cara kerjanya dengan debug vs rilis dibangun?
Dave Moore

Saya tidak yakin apakah ada solusi yang sesuai untuk memuat debug / rilis rakitan melalui DEVPATH, ini dimaksudkan untuk digunakan hanya untuk rakitan bersama, saya tidak akan merekomendasikannya untuk membuat build biasa. Perlu diketahui juga bahwa versi perakitan dan GAC diganti saat menggunakan teknik ini.
Aleksandar

1

Ini mungkin bukan praktik terbaik, tetapi ini adalah cara saya bekerja.

Saya memperhatikan bahwa Managed C ++ membuang semua binernya ke dalam $ (SolutionDir) / 'DebugOrRelease'. Jadi saya membuang semua proyek C # saya di sana juga. Saya juga mematikan "Salin Lokal" dari semua referensi ke proyek dalam solusi. Saya telah melihat peningkatan waktu pembangunan dalam solusi 10 proyek kecil saya. Solusi ini adalah campuran dari C #, C ++ terkelola, C ++ asli, layanan web C #, dan proyek pemasang.

Mungkin ada sesuatu yang rusak, tetapi karena ini adalah satu-satunya cara saya bekerja, saya tidak menyadarinya.

Akan menarik untuk mengetahui apa yang saya langgar.


0

Biasanya, Anda hanya perlu Salin Lokal jika Anda ingin proyek Anda menggunakan DLL yang ada di Bin Anda vs apa yang ada di tempat lain (GAC, proyek lain, dll.)

Saya cenderung setuju dengan orang lain bahwa Anda juga harus mencoba, jika mungkin, untuk memecah solusi itu.

Anda juga dapat menggunakan Pengelola Konfigurasi untuk membuat sendiri konfigurasi bangunan yang berbeda di dalam satu solusi yang hanya akan membangun rangkaian proyek tertentu.

Tampaknya aneh jika semua 100 proyek mengandalkan satu sama lain, jadi Anda harus dapat memecahnya atau menggunakan Pengelola Konfigurasi untuk membantu diri Anda sendiri.


0

Anda dapat meminta referensi proyek Anda menunjuk ke versi debug dll. Dari pada skrip msbuild Anda, Anda dapat mengaturnya /p:Configuration=Release, sehingga Anda akan memiliki versi rilis aplikasi Anda dan semua rakitan satelit.


1
Bruno - ya, ini bekerja dengan Referensi Proyek, yang merupakan salah satu alasan kami pertama kali menyelesaikan dengan solusi proyek 100. Itu tidak bekerja pada referensi di mana saya menjelajah ke rilis Debug yang sudah dibangun - saya berakhir dengan aplikasi Rilis yang dibangun terhadap perangkat Debug, yang merupakan masalah
Dave Moore

4
Edit file proyek Anda dalam editor teks dan gunakan $ (Konfigurasi) di HintPath Anda, mis. <HintPath> .. \ output \ $ (Configuration) \ test.dll </HintPath>.
ultravelocity


0

Jika referensi tidak terkandung dalam GAC, kita harus mengatur Salin Lokal ke true sehingga aplikasi akan berfungsi, jika kami yakin bahwa referensi akan diinstal sebelumnya di GAC maka dapat disetel ke false.


0

Yah, saya tentu tidak tahu bagaimana masalah tersebut berhasil, tetapi saya telah melakukan kontak dengan solusi build yang membantu dirinya sendiri sehingga semua file yang dibuat diletakkan di ramdisk dengan bantuan tautan simbolik .

  • c: \ folder solusi \ bin -> ramdisk r: \ folder solusi \ bin \
  • c: \ folder solusi \ obj -> ramdisk r: \ folder solusi \ obj \

  • Anda juga dapat memberi tahu tambahan studio visual direktori temp yang dapat digunakan untuk pembuatan.

Sebenarnya bukan itu yang terjadi. Tapi itu benar-benar menyentuh pemahaman saya tentang kinerja.
Penggunaan prosesor 100% dan proyek besar dalam waktu kurang dari 3 Menit dengan semua ketergantungan.

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.