我想問你，開發和部署一個通常具有一些標準功能的應用程序有什麼經驗，但應用程序也可以具有客戶特定功能。
例如：應用程序項目結構問題
你會如何解決這個問題？
您是否有一個項目可以在其中部署所有應用程序，然後通過某種配置文件確定哪些功能在特定應用程序中可用？
你會爲每個客戶有一個項目嗎？這就是我現在正在做的事情，但這裏的問題是，如果需要修正標準功能中的錯誤，我必須在每個項目中修復這些錯誤。
任何其他建議，非常歡迎。
該應用程序是在Delphi和C＃中開發的。
沒有明確的每個客戶都沒有一個項目，您可以爲每個客戶提供一個解決方案，您可以根據設置需要彙總所有項目。
只是給你一個替代插件架構，這是正確的路要走，但也相當複雜。
Option1。
像日曆放在分離DLL項目其他的東西（每功能之一）
創建VS解決方案，在那裏你agregate所有項目
把常用功能特定的設置+核心。因此，customer1將擁有Customer1Silution和Core以及他需要的所有額外項目，customer2是Core和其他內容的解決方案。
Option2。
有一個大的設置爲每個人和基於其配置/許可證啓用/禁用訪問用戶到一個額外的功能。
取決於您的資源，如時間，經驗，與您一起工作的人，客戶，您可以選擇更適合您的選項。
1基於插件：可能是最好的一個，但它很複雜，如果你以前從來沒有做過類似的事情，那麼需要一段時間才能熟悉它。
選項1既簡單又快捷，但如果客戶數量和配置變得遲緩，您將跳入規模問題。
選項2是這兩者之間的平均值，但請注意您的設置維度。
考慮到您在解決方案中引用了項目和nit DLL，如果您在一個解決方案中修復了Core中的問題，它也會影響到所有其他解決方案。
謝謝。大多數人都贊成插件架構，所以我會嘗試。 – Poku
@Poku請注意，插件體系結構傾向於創建一些「gasworks」 - 您必須將其寫入真正的模塊化設計中，這並不容易。 Delphi EXE並不是那麼龐大，從我的實驗來看，密碼保護的訪問更容易實現和維護。 –
我的公司通過向所有客戶提供所有功能來解決該問題。這使開發更簡單，並使我們能夠花更多時間在改進產品上，而不必花費時間處理可選功能的複雜性。
我們有時會遇到來自客戶的輕度抵制，他們希望價格較低的版本具有較少的功能，但這從來不是銷售問題。
另一方面，如果你賣的客戶更便宜的功能較少的版本，他們很容易試圖擺脫這些更便宜的版本。這可能導致他們不喜歡軟件，因爲他們購買了便宜的殘廢版本。我強烈地相信能夠爲用戶提供最好的產品。
此建議可能不適合您的個人情況，但您確實表示歡迎任何意見。
感謝您的回覆並分享您的期滿，但這不是我的選擇。 – Poku
每個客戶的一個版本不是一個好主意，恕我直言。它會在一天或之後停滯你的銷售。
最好讓所有的功能都發布給所有的客戶，例如只保留一個軟件，但是被一個密碼鎖住。您可以在軟件安裝時提供唯一的許可證號碼以識別客戶（將其名稱放在許可證中），然後根據此許可證號碼計算一些密碼，以便在付費時根據請求解鎖某些功能。這個密碼可以很容易地通過網站自動完成，而且成本最低。
或者您也可以讓所有功能都可用於測試，但鎖定打印或保存 - 僅讓客戶考慮花費一些錢來獲得這個「不錯的附加功能」。
有時，擁有所有功能往往會創建一個「Gasworks」應用程序。您可能需要一個單獨的安裝應用程序，以根據客戶的需求定製應用程序。值得思考這個架構。
即使使用修訂版本控制，多個版本也是一個噩夢來維護：例如，將所有修補程序回退到先前版本需要花費大量時間。如果你不必（因爲管理目的/認證版本等），不要「分支」你的軟件。
除了別人所說的還有另一種選擇：條件定義。
通過條件編譯，您可以使用IFDEFS（IFDEF EmployeeCalendar，IFDEF SearchFunction ...）封裝特定特定代碼。然後，對於每個客戶端，只複製項目文件並根據要包含的功能設置條件定義。
如果客戶想要/支付額外的功能，只需將其添加到該客戶的項目文件中的條件定義。
這與模塊方法（BPL/DLL）類似，但避免了額外部署/管理額外文件的額外成本。缺點是特徵集在編譯時是固定的。
使用BPL/DLL，您可以在運行時動態加載其他模塊，但如果這對您的情況不重要，則條件定義可能是一個不錯的選擇。
當然，如果你的功能不容易分開，那麼你可以在代碼中得到很多IFDEF，但是你的問題是功能的明顯分離，這也是模塊的問題。
您使用的是版本控制嗎？聽起來好像你不是。 –
我正在使用版本控制，是的。 – Poku
但您不在項目之間共享文件？ –