2013-03-27 49 views
1

我有以下的構建目標設定做我展開時發佈,由Hanselman在他的Tiny Happy Features #3提到,在許多其他地方也記作什麼,我認爲是推薦的方法:MSDeploy通過的MSBuild複製所有文件,而不是同步文件

msbuild my_web_application.csproj /p:Configuration=Production; 
            DeployOnBuild=true; 
            PublishProfile=Production; 
            VisualStudioVersion=11.0; 
            AllowUntrustedCertificate=true; 
            AuthType=NTLM 

這做這項工作,並替換部署一步,我以前通過調用MS命令行上部署有:

msdeploy.exe" -source:package="c:\source_to_my_web_application.zip" -dest:auto,my_server_name,includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"c:\source_to_my_web_application\Package.SetParameters.xml" 

我可以在這兩種方法中看到的最大的區別是,命令行調用只會pu sh修改有修改的文件,而msbuild調用每次都通過整個Web應用程序發送。

有沒有辦法讓msbuild版本做「同步」行爲,就像直接調用msdeploy爲我做的那樣?

回答

0

從我已經能夠建立,從包(如爲這個特定的MSBuild命令創建一個)的同步將發現它試圖部署的本地工作副本相關的差異。

如果我做了一個新的簽出,然後構建和部署,它會發布整個Web應用程序。

如果我在該工作副本上進行清理並重建,它將只發布重建的dll。

如果我做了一個構建,它只會發佈已轉換的web.config文件,以及其他一些隨機dll,我無法使用韻或理由。

我猜,我們的底線是,在我們的CI服務器設置中,應該假定所有文件都將發佈到服務器上,如果發佈次數少於此次數,它就是帶寬獎金。

作爲一個方面說明,我也遇到了隨機,不可靠的404錯誤,同時執行其他正常的ms部署命令。他們似乎是間歇性的,可以在我自己的工作站,我的同事和CI服務器之間有所不同,這樣MS Deploy服務將在每次連續呼叫幾秒鐘內返回一個404或執行正常。我發現這種行爲的解決方案從重新啓動Visual Studio到卸載並重新安裝各種組件,並確保您按照正確的順序執行,並且只有以「ary」結尾的任何月份的第三週的第二個星期二。 ..

對我來說,這個工具是粗略的,如果你能得到一個可靠的工作設置,這是一個奇蹟,你不應該再次觸摸它,並祈禱硅神它保持這種狀態。