这是一个架构问题。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。
我曾与一个解决方案，这样做，它确实为我们面向外部的网站工作，但它是一个维护的母马。