Nuget的最佳做法：調試還是發佈？

目前，我將發佈版本與官方版本的Nuget打包到nuget.org，但我使用Nuget將調試版本打包爲符號源碼推送到symbolsource.org。Nuget的最佳做法：調試還是發佈？

編輯：（喬恩斯基特，與野田開發的時間有些偏）

的NuGet現在支持推動雙方的NuGet畫廊和 symbolsource.org（或類似的服務器），as documented。不幸的是，有兩個相互矛盾的要求，在這裏：

當使用庫，而無需任何調試剛剛，你真的想要一個發佈版本。畢竟，這就是發佈版本的目的。

爲了進行診斷而調試到庫中時，您確實需要一個調試版本，並禁用所有適當的優化。畢竟，這就是調試版本的作用。

這樣會很好，但是NuGet不允許在同一個包中以有用的方式發佈發佈和調試版本。

所以，選用的是：

分發調試版本給大家（如在文檔的例子），並與任何尺寸和性能的命中居住。

將發佈版本分發給每個人，並且存在稍微受損的調試體驗。

尋找一個非常複雜的分發策略，可能會提供單獨的發行版和調試軟件包。

前兩個真正歸結爲調試和發佈版本之間差異的影響......雖然值得注意的是，想要步入庫的代碼之間也有很大的區別，因爲您希望檢查一些行爲，並且想要調試庫的代碼，因爲您認爲自己發現了一個錯誤。在第二種情況下，最好將庫的代碼作爲Visual Studio解決方案並以這種方式進行調試，所以我沒有太在意這種情況。

我的誘惑是隻保留與發佈版本，並期望相對很少有人會需要調試，和誰做的人不會在發佈版本的優化受到影響多。（無論如何，JIT編譯器會進行大部分優化。）

那麼，有沒有其他的選擇我們沒有考慮過？是否有其他因素會影響平衡？將NuGet軟件包推向SymbolSource是否足夠新，以至於「最佳實踐」還沒有建立起來？

來源

2012-11-21 gzak

我正要問同樣的問題 - 雖然目前我正在將Release配置推送到符號源，因爲我只是使用'nuget pack ... -Symbol'並推送生成的包。。 –

請記住，如果我在自己的問題中編輯了更多關於自己情境的細節？我想這會澄清一些問題的原因。 –

繼續前進。今天晚些時候我會趕上所有這些新帖子。 – gzak

發言SymbolSource，我認爲最好的做法是：

按壓釋放二進制+內容包，只nuget.org（或任何其他生產飼料）
推調試二進制+內容包以發展飼料：
- 內部部署上nuget.org上myget.org
- 作爲預發行包。
將發佈和調試二進制+符號包推送到symbolsource.org或任何其他符號存儲。

雖然我們在這，它是釋放和調試在.NET中建立真正差距不大一種常見的誤解，但我假設分化的，因爲這可能會或可能不包括各種代碼在這裏在任何版本中，如Debug.Asserts。

也就是說，將兩種配置都推送到SymbolSource是非常值得的，因爲您只是永遠不知道什麼時候需要調試生產代碼。在生產中遠程使其更難。發生這種情況時，您需要從工具中獲得幫助。我顯然不希望任何人。

關於版本控制還有一個問題需要考慮：是否有2個不同的軟件包（內置調試和發行版）共享1個版本號是否正確？ SymbolSource會接受這一點，因爲它提取包並將二進制文件存儲在單獨的構建模式分支中，因此只允許NuGet相應地標記包。目前沒有辦法確定程序包是調試模式還是釋放模式。

來源

2013-02-01 07:31:07 TripleEmcoder

「發佈兩個版本到NuGet」部分是棘手的一點。我總是發佈Noda Time的Release版本，理由是我必須在兩者之間進行選擇。（我有一個nuspec文件，而不是僅僅從C＃項目中完成它）。您提到調試生產代碼就好像只有一個發佈版本那樣困難得多 - 儘管之前的「它們沒有多少區別」。我知道調試版本中的NOP，顯然是'Debug.Assert'等等，但是您可以在調試時擴展（在您的答案中）含義。使用發佈版本有多糟？ –

我的意思是隻是想讓符號可用於所有正在使用的二進制文件：如果在調試版本和發行版本都可以使用，則需要爲兩者提供符號。他們不需要在代碼方面有很大差異，但他們在校驗和方面會有所不同，這使得加載符號不可能沒有一些黑客行爲。 – TripleEmcoder

對。我可能的解決方案是*只發布釋放二進制文件，但我擔心在調試方面會有多大的傷害。例如，缺乏NOP意味着你不能添加斷點？ –

Creating and Publishing A Symbol Package中的示例將Debug目錄中的文件引用爲dll和pdb文件的源。

指定符號包裝內容

符號包可以通過約定來建造，從在上一節中所描述的方式構成的文件夾，或者它的內容可以使用該文件部分被指定。如果你想建立之前描述的例子包，你可以把你的nuspec文件這樣的：

<files> 
    <file src="Full\bin\Debug\*.dll" target="lib\net40" /> 
    <file src="Full\bin\Debug\*.pdb" target="lib\net40" /> 
    <file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" /> 
    <file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" /> 
    <file src="**\*.cs" target="src" /> 
</files>

由於出版符號的目的是爲了讓別人來逐步執行代碼時調試，似乎最謹慎的做法是發佈用於調試的代碼版本，而不進行可能影響代碼步驟的優化。

來源

2013-02-01 07:28:22 tvanfosson

是的，這就是*例子*所做的 - 但我寧願不要以調試的能力勝過大多數開發人員僅僅運行發佈版本的願望。據我所知，問題在於NuGet沒有發佈發佈和調試版本的方法。（這對我來說也是輕微的痛苦，因爲它意味着爲簽名的調試版本創建另一組配置......） –

這裏我們進入一個小小的主觀性。通常情況下，我選擇「最佳實踐」的方式應該是作者所建議的，無論是明示的還是暗示的，因爲我認爲他們比我有更多的洞察力（或假設最終會出現例子）。比如說，我認爲符號應該與我使用的版本相匹配。我通常不會使用我認爲可能需要調試的軟件包，除非源代碼是公開的，並且如果需要，我可以從頭開始編譯，所以缺少打包的調試版本並不特別重要。 – tvanfosson

在我的情況下，如果有人需要調試野田時間，因爲他們認爲野田時間有錯誤，他們最好是下載源代碼（當然他們可以這樣做）。不過，能夠進入Noda Time源代碼以查看發生了什麼仍然很有用。基本上我認爲有至少兩種不同的調試方案，用不同的解決方案... –

我完全同意你的結論。帶有RELEASE和SymbolSource的NuGet包進行調試。直接進入軟件包似乎非常少見，並且啓用優化的偶爾調試失誤可能是可以接受的。

如果確實有問題，我認爲理想的解決方案是讓NuGet支持它。例如，想象一下，如果在調試時，它可以用包含在SymbolSource包中的版本替換髮布DLL。

然而，理想情況下，nuget pack SomePackage -Symbols針對發行版將創建發行版nuget包，但是是調試符號包。並且VS插件將被更新爲足夠聰明以查看關聯並在調試器中運行時拉入調試程序集並加載它們。有點瘋狂，但會很有趣。

但是，我只是沒有看到足夠的人抱怨這件事，現在是值得的。

NuGet團隊接受拉請求。:)

來源

2013-02-04 21:41:11 Haacked

我不知道我理解你的第二句話 - 我懷疑OP（我編輯之前的）是上工推向SymbolSource的調試版本。如果*版本*的PDB最終在SymbolSource而不是調試版本中，您是否會設想出重大問題？或者那是你所倡導的，我只是誤解了？ –

「但是，我只是沒有看到足夠的人對此抱怨，目前它是值得的。」也許他們沒有抱怨，但如果你問用戶的樣本什麼，他們想到了這一點，我敢打賭，你會發現，大多數人會在這個特別的一步承認有點混亂的（東西發佈到NuGet.org和SymbolSource.org）。如果你問他們最終選擇什麼，你可能會發現沒有單一的商定做法，每個人都會做自己的事情。 – gzak

我想抱怨這個，我在哪裏註冊？ – Alex

Nuget的最佳做法：調試還是發佈？

回答

相關問題