這是一個架構問題。WSS 3.0 as應用平臺
我們正在建立一個基本的工作流程，需要外部面臨的文件管理網站的過程。外部應用程序需要打上品牌，應該有能力上傳和下載文件，並支持版本。我們有決定使用WSS 3.0作爲協作工具，因爲它具備我們所需的所有功能。我們計劃通過爲每個客戶端定製品牌來支持多個客戶端。
我的問題是我們應該向外部客戶公開WSS，還是在應用層中使用WSS構建標準的ASP.NET應用程序，並讓ASP.NET應用程序使用WSS API/Web服務與WSS進行交互。可以輕鬆定製ASP.NET應用程序，而無需對WSS進行任何更改。內部用戶不需要任何品牌，因此可以轉到面向內部的WSS站點來執行工作流程活動。自從我開始WSS開發以來，構建特色和打入品牌一直是一個挑戰。
請讓我知道您的想法。
如果您不太瞭解SharePoint，那麼創建和展示用戶界面將會很困難。你可以做到嗎？絕對。你應該這樣做嗎？這取決於您的要求，以及您對SharePoint的專業水平。在我看來，最簡單的方法是創建一個ASP.NET應用程序並與SharePoint建立接口，但我一天中有90％的時間都在使用ASP.NET，而且每年只做一次SharePoint開發。
根據我的經驗，如果你不得不問你是否應該用某種工具建立一個新產品等，答案一般都知道。如果我無法自己回答這個問題，也許有些人會環顧這個工具，但我儘量不要在一個重大項目中使用它，因爲這意味着，我不知道它是否足夠好，以防止意想不到的事情發生，就產生了。
SharePoint很大。真的很大。因此，如果您計劃在您的客戶和SharePoint之間開發自家制作的中間層，請準備好進行大量工作，除非您計劃僅公開一小部分SharePoint界面。
我建議公開WSS，並通過創建符合SharePoint單獨無法滿足的要求的Web部件，頁面和列表來建立您的應用程序，而不是在WSS框架附近。這應該將您的工作量減少到可管理的程度。
查看諸如VSeWSS或WSPBuilder之類的工具以減輕您的WSS 3.0開發（應該使用Visual Studio），並在適當的時候利用SharePoint Designer。
如果你在WSS下面做了一個自定義外套，那麼你本質上就是編寫與該平臺一起提供的代碼，尤其是使用SharePoint。我認爲價格是決定你的決定的一個因素，或者你不會單獨使用WSS。在這種情況下，將WSS用作代碼層可能很誘人，但我認爲要使這項工作順利進行將會非常困難。
根據您的業務模型，我會研究託管SharePoint解決方案可以執行的操作，特別是如果您可以在其平臺上託管自定義SharePoint網站定義。
需要非常強大的知識產權或財務要求才能讓我考慮在WSS之上封裝asp.net。
我曾與一個解決方案，這樣做，它確實爲我們面向外部的網站工作，但它是一個維護的母馬。