我有多个针对不同客户的 SQL Server 数据库(相同架构)。他们将共享一个通用的 ASP.NET Web 应用程序。如果其中一位客户想要网页的自定义版本,我们将在他的目录(或项目)中创建一个新版本。
示例:
/Main Application/WebPage.aspx
/Main Application/WebPage2.aspx
/Main Application/Customer 1/WebPage.aspx
/Main Application/Customer 2/WebPage.aspx
目前,我的项目结构如下
Solution (Main application)
ASP.NET Main Project
Other projects (BLL, DAL, etc.)
Solution (Customer 1)
ASP.NET Project
Other projects (BLL, DAL, etc.)
Same thing for Customer 2
在每个客户解决方案中,我添加了对主应用程序项目的引用,以解决依赖关系并使用未自定义的网页。
每个 ASP.NET 项目代表一个不同的 IIS 虚拟目录,因此本示例中有 3 个。 (/Main、/Main/Customer1、/Main/Customer2)。
我现在遇到的问题是当我尝试连接到正确的数据库时。每个解决方案中的每个 ASP.NET 项目都有一个包含客户数据库连接字符串的 web.config 文件。当我从基本 ASP.NET 项目(主应用程序)运行程序(假设为 WebPage2.aspx)时,我无法获取此连接字符串,因此我不知道要连接到哪个数据库。
我尝试将所有连接字符串放入主应用程序 web.config 中,但在项目启动时找不到一种方法来引用正确的连接字符串。似乎没有办法设置自定义属性,让我可以在解决方案级别指定当前解决方案的连接字符串名称(或键)。
对此有什么想法或想法吗? 我不介意改变我的项目结构,但重要的是每个客户都有自己的解决方案,这样我们才能保持干净和分离。
最佳答案
如果我是您,我会考虑从您的主应用程序库创建一个 NuGet 包。 (NuGet 包可以完全保密,因此您不必担心开源要求...)
使用 NuGet 包,您只需将包安装到客户的解决方案中,就可以复制 dll 程序集、aspx 文件、xml 配置以及每个客户几乎需要的任何其他内容。您可以在 IIS 中为每个客户创建一个单独的虚拟目录(甚至网站),他们都将拥有运行所需的一切。
最重要的是,通过这种方式,您可以获得另一件非常重要的事情:可维护性。您可以继续在主解决方案中开发新功能和错误修复,并且每当您想要将某些内容推送到客户站点时,您只需将更新发布到 NuGet 包即可。然后,您可以将该软件包更新安装到一个或所有客户特定站点中,但不必同时执行此操作。如果某个客户站点由于某种原因需要落后,也不会阻止其他客户访问新功能。
Creating a NuGet package is easy ,与单独解决方案中的多个站点依赖于另一个解决方案的构建的解决方案相比,它将带您进入可维护性天堂,您甚至无法同时检查所有代码是否存在编译错误...
关于c# - 多个 ASP.NET Web 应用程序依赖于一个公共(public)基础应用程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6816803/