爲什麼我應該通過svcutil使用Visual Studio服務引用？

所以好像我有幾個主要的選項讓WCF服務代理代碼到Visual Studio中的一個項目時：爲什麼我應該通過svcutil使用Visual Studio服務引用？

使用Visual Studio的內置工具爲Service References
使用一個簡單的svcutil命令，類似於svcutil http://[my endpoint] /namespace:[my namespace] /noconfig（因爲我使用一些跨項目相當標準的綁定），並拖動結果文件到我的項目（或就地升級）。

需要明確的是，選項2感覺最好的一個，albiet用於更新沒有內置的工具。但是服務引用對話框生成的就像一個zillion文件。 我錯過了VS服務引用有沒有模糊的好處？

來源

2011-09-19 Brandon Linton

他們基本上是一樣的東西。 –

Visual Studio基本上在後臺調用svcutil。然而，程序員的很多都不敢開了一個命令提示符並運行一個命令行工具 - 這就是爲什麼Visual Studio中有'添加服務Reference'對話框.... –

是的，我知道他們是在幕後相同，但它使用一些/真棒開關生成所有這些XSD和其他文件的一些好處？ –

如果你還擁有服務，我說沒有使用任一個。相反，將您的合同，實體和客戶端代理拆分爲不同的程序集，您可以在服務和客戶端上使用它們。

有點像在WCF The Manual Way... The Right Way說明。

來源

2011-09-19 17:13:19

我完全同意！ –

我在很多地方聽到這一點，我認爲這是即使在文檔■設計某處（也許是另外一個問題），但不要我，然後還需要各地的下載和更新這些組件一個重量級的管理策略？我已經完成了svn：externals併爲NuGet考慮了這一點，但除了易於更新（和svn：externals幾乎太容易將代碼偷偷地編譯到構建中）之外，我不確定我以外購買的是什麼稍微多一些的DRY代碼。 –

如果你擁有所有的代碼，這應該沒有問題。您不必引用程序集;您可以引用服務引用的相同項目。每當你建立，你的客戶也會被更新。 –

爲什麼你建立一個.NET項目，VS，而不是通過命令行手動調用編譯器一樣的道理。 IDE的I表示Integrated，它可以幫助你，所以你不需要從許多分離的地方和程序手動完成這些事情。

通常有一個辦法用手或用文本編輯器和命令提示做很多的那些東西，但讓富有成效:-)

來源

2011-09-19 17:10:13

在UI工具v。命令行上達成一致。那麼你說可用性是唯一的好處嗎？ –

爲什麼我應該通過svcutil使用Visual Studio服務引用？

回答

相關問題