作爲一個長期的潛伏者，我彈出了一個棘手的關於CruiseControl.NET，Subversion和遠程存儲庫的問題。問題如下：CruiseControl.NET服務/ Subversion - 無法連接到遠程存儲庫
將Windows Server 2008 SP2上運行的遠程Subversion 1.6.6存儲庫使用Apache 2.2.14作爲網關，以便在端口80和443上啓用訪問 - 我們將未加密的流量重定向到安全端口，以及我們有一個正確配置的使用自簽名證書運行的SSL層。這一切都有效 - 我可以將瀏覽器從本地計算機（XP SP2或Server 2008 SP2）指向此存儲庫，輕鬆通過證書驗證，根據存儲庫ACL進行身份驗證，並查看其中的內容。同樣，在本地機器上執行的SVN命令（無論是在命令行還是通過TortoiseSVN）都可以完美地工作。
現在添加CruiseControl.NET 1.4.4.83 - 在本地機器上運行一個簡單的腳本，從遠程存儲庫中提取一些源代碼，並構建一個非常基本的應用程序。這個相同的腳本完全可以對付本地存儲庫，所以唯一的區別是Subversion URL現在指向遠程服務器。
如果我在自己的帳戶下的命令行shell（ccnet.exe）中運行CC.NET，它可以工作。
但是，如果我將CC.NET作爲服務運行（ccservice.exe），則會失敗;默認情況下，它作爲LOCALSERVICE運行，但我已經改變了這個以使用我的憑據運行。在這種模式下，第一個發佈的Subversion命令（SVN LOG）失敗，抱怨它無法連接到服務器。
我已經花了好四五天時間來研究這個問題;我知道這不是一個防火牆類型的問題，因爲與CC.NET問題完全相同的命令在命令行shell中工作，當然，我可以通過TortoiseSVN和瀏覽器連接到遠程服務器。這不是SSL和/或證書阻礙，因爲我已經導入了證書 - 再一次，這可以在使用TortoiseSVN，瀏覽器或命令行中的SVN命令的「手動」模式下正常工作。這不是一個DNS解析問題，因爲我可以指定遠程服務器的實際IP地址，但它仍然無法連接 - 但當然連接好，如果我在命令行模式下運行...
我甚至已經下載並通過CC.NET源代碼來查看是否有任何奇怪的事情發生。據我所見，在服務模式下運行時發出命令的唯一區別是，AllocConsole調用已準備好一個控制檯，以便Subversion命令進程在產生時鎖定。
在這個階段，我可以做出的最好的猜測是，AllocConsole會話與標準命令行會話有某種根本的不同 - 即使服務在我的用戶憑證下運行，不知何故AllocConsole沒有'正確的'網絡訪問。但是，我不太瞭解AllocConsole或CC.NET源代碼以證明這一點，因此我陷入了僵局。
目前，我在命令行模式下運行CC.NET;然而，這只是讓人感到不滿意，因爲我們更喜歡在服務模式下運行它（這對我們本地域中的存儲庫來說工作正常），以避免創建計劃任務以在機器啓動時啓動它的必要性。
任何人有任何建議嗎？