具有多個實例＆web.configs的單個ASP.net站點

Question

我們有一個運行在IIS服務器上的傳統ASP.net驅動的站點，該站點由中央團隊開發並被多個客戶使用。然而，每個客戶都有自己的網站aspx文件副本和web.config文件。這是由於良好意義的支持工程師對源aspx文件的副本沒有被折回到中央源代碼中所造成的問題，所以我們的代碼基礎是分歧的。我們目前的文件夾結構看起來像： OurApp /來源ASPX &默認的web.config
customer1表/來源ASPX &的web.config
顧客2 /來源ASPX &的web.config
Customer3 /來源ASPX &的web.config
Customer4 /來源ASPX &的web.config
...

這是我想改變成只是一個定製的web.config文件和所有客戶分享交流各自的客戶ommon源文件集。因此，像： OurApp /來源ASPX &默認的web.config
customer1表/ web.config中
顧客2/web.config中
Customer3/web.config中
Customer4/web.config中
...

所以我的問題是，我該如何設置？我是新來的ASP.net和IIS，因爲我通常在家使用PHP和Apache，但我們在工作中使用ASP.net和ISS。

---

源代碼控制使用，我打算再培訓的支持工程師，但有什麼辦法，以避免源ASPX文件的多個副本？我討厭那種重複！

Answer 1

如果您在單個應用程序實例上死了，您可以在單個web.config中使用自定義ConfigurationSection後完成您的工作。對於基礎知識，請參閱：

• http://haacked.com/archive/2007/03/12/custom-configuration-sections-in-3-easy-steps.aspx
• http://msdn.microsoft.com/en-us/library/2tw134k3.aspx

示例XML可能是：

<YourCustomConfigSection> 
    <Customers> 
    <Customer Name="Customer1" SomeSetting="A" Another="1" /> 
    <Customer Name="Customer2" SomeSetting="B" Another="2" /> 
    <Customer Name="Customer3" SomeSetting="C" Another="3" /> 
    </Customers> 
</YourCustomConfigSection> 

現在，在您ConfigSection屬性，揭露名稱，SomeSetting，和另一個。當訪問或設置屬性時，使用條件（請求域或其他唯一標識客戶的東西）來決定使用哪一個。

通過適當的實施，應用程序開發人員不需要知道幕後發生了什麼。他們只是使用CustomSettings.Settings.SomeSetting，不用擔心哪個客戶正在訪問該應用程序。

Answer 2

使用外部源代碼管理應用程序並根據需要繼續更新更新。

不管怎樣，讓實時網站由支持工程師實時更新並不是一個好主意。

Answer 3

我知道這看起來很煩人，但重複實際上是一件好事。這裏的問題在於您的進程，而不是系統設置的方式。

保持網站分離實際上是一件好事。雖然看起來像「重複」，但事實上並非如此。這是分離。應該積極勸阻你的支持工程師修改產品代碼。

您應該考慮更改您的流程，以便隨時隨地進行更改。從長遠來看，這會使你的一切變得更加容易。

要真正回答你的問題，答案是否定的，你不能這樣做。原因是web.config不是用來存儲用戶級別的設置，而是設計用來存儲每個應用程序的實例設置。在你的情況下，你需要每個用戶的應用程序實例，這意味着單獨的配置文件。

爲了讓系統正常工作，您需要能夠搶先告訴應用程序要使用哪個配置文件，如果沒有用戶的某種輸入，這是不可能的。

Answer 4

根據Web配置中的實際內容以及客戶之間的不同設置，您可以選擇使用單個Web配置，並將其他客戶特定配置選項存儲在數據庫或其他自定義xml /文本文件中。只要web.config中的特定客戶設置不需要對IIS的運行方式進行任何操作，並且您只是使用它來存儲值，那麼此解決方案可能會爲您解決問題。

Answer 5

如果我理解正確，聽起來像你有多個部署（每個客戶端一個），唯一的區別是web.config，對吧？

首先，雖然我不知道您的獨特情況，但我通常會敦促您繼續單獨安裝。它通常允許更多的靈活性。關閉我的頭頂：你是否曾經有過定製，或不同的客戶端運行不同的版本？你是肯定？在這裏保持靈活性的最簡單方法是繼續單獨安裝。

在我看來，如果你的做法是正確對齊的話，它根本不難看。根據你提到的一些事情，你在那個領域遇到了麻煩 - 顯然，可能的源代碼控制買入/培訓問題。但你知道這一點。我也會仔細看看你的部署過程等等。我有一種感覺，你可能在這方面有進一步的問題，我的意思是絕對沒有進攻。

這就是說，讓我們假設你想繼續前進。

你沒有說所有的客戶端是否共享一個共同的數據庫，但我想沒有，因爲設計這種類型的系統往往是不值得額外的複雜性（這可能是嚴重的在任何大小的系統）所以人們經常選擇讓他們分開。

這意味着你有連接字符串存儲在某個地方。通常這將是web.config ...所以這似乎打破了我們的計劃。

真的，這種情況明顯優雅幾乎總是由似地介紹了挑戰偏移。如果我想過這個問題夠硬，我也許可以通過引入智能地管理連接字符串或也許鑽研在web.config中直接讓你的所有登錄信息另一個數據庫中找到解決的辦法（這是可能的，但......不理想）但是我的直覺說這項工作將被浪費，因爲有一天你會最終回到你現在正在做的事情上。

另外：直接在生產中更改代碼顯然不是這裏的最佳實踐。但是，如果你在一個擁有大量流量的單一共享平臺上，那永遠不會發生。食物的思想。

讓我知道如果我失去了一些東西！

Answer 6

那麼，你可以嘗試利用硬鏈接： http://msdn.microsoft.com/en-us/library/aa365006.aspx ...你問了它。

另一個問題可能會感興趣： Techniques For Distributing ASP.NET User Controls Across Projects

Answer 7

再次感謝大家的答案。在仔細閱讀並認真思考之後，我認爲我會做的就是暫時保留多個實例，並且我會先嚐試改進我們的更新過程。那麼我將開發一個新版本的應用程序，該應用程序在數據庫層中具有用戶配置信息，然後根據某人的建議，根據請求域或URL選擇用戶。這樣我就可以有一個應用程序實例乾淨地支持多種不同的客戶端配置。

由於大部分客戶端配置數據確實與表示或數據源相關，所以沒有什麼複雜的。我認爲我們最終得到了多個應用程序實例，主要是因爲原始程序員並沒有期待多個客戶，也沒有爲此設計，所以當有人過來後又添加了第二個客戶時，他們只複製了浪費的應用程序，因爲每個實例與原文約99.99％相同。

Answer 8

我正在實施這個，因爲我們說話。

在主web.config中，每安裝一個項目。它指向我爲每個客戶端構建的自定義配置文件（以及自定義masterpage，css，圖像等）。

使用WebConfigurationManager.OpenWebConfiguration，我打開它們的子目錄中的新webconfigs。我通過使用System.Web.HttpContext.Current.Request.Url.OriginalString來確定使用哪一個，並確定調用我的uRL。基於該URL，我知道要使用哪個web.config。

從那時起，客戶端都使用相同的代碼庫。他們也有自己的數據庫。

當我們進行更新時，必須更新30-40個安裝的想法讓我驚恐不已。我們不希望支持30-40個代碼庫，因此除了母版頁，CSS和圖像之外，不會進行定製。

我寫了一個自定義類lib，知道如何切換到正確的webconfig，並閱讀我用我們所有設置構建的自定義部分。

我現在唯一的問題是FormsAuthentication Cookie。我需要能夠切換。不幸的是，該名稱的財產是隻讀