问题描述
我有多个SQL Server数据库(相同的架构),针对不同的客户。他们将共享一个共同的ASP.NET Web应用程序。如果这些客户之一想要一个网页的定制版本,我们将创建在他的目录(或项目)一个新的。
I have multiple SQL Server databases (same schema) for different customers. They will be sharing a common ASP.NET web application. If one of these customers wants a customized version of a web page, we will create a new one in his directory (or project).
例如:
/Main Application/WebPage.aspx
/Main Application/WebPage2.aspx
/Main Application/Customer 1/WebPage.aspx
/Main Application/Customer 2/WebPage.aspx
目前,我有以下项目结构
At the moment, I have the following project structure
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
在每个客户的解决方案,我添加了一个参考主要应用项目,以解决依赖和使用也未定制网页。
In each customer solution, I added a reference to the main application project to resolve the dependencies and also to use the web pages that are not customized.
每个ASP.NET项目重新presents不同的IIS虚拟目录,所以我们有3个在这个例子。 (/主,/主/的customer1,/主/ CUSTOMER2)。
Each ASP.NET project represents a different IIS virtual directory, so we have 3 for this example. (/Main, /Main/Customer1, /Main/Customer2).
我现在的问题是,当我尝试连接到正确的数据库。每个解决方案内每个ASP.NET项目与客户的数据库连接字符串web.config文件。当我运行一个程序(比如说WebPage2.aspx)从基础ASP.NET项目(主要用途),我不能把这个连接字符串,所以我不知道要连接到哪个数据库。
The problem I have now is when I try to connect to the right database. Each ASP.NET project inside of each solution have a web.config file with the customer's database connection string. When I run a program (let's say WebPage2.aspx) from the base ASP.NET project (Main Application), I cannot get this connection string so I don't know what database to connect to.
我试图把我所有的连接字符串在主应用程序的web.config,但我不能找到一种方法来引用正确的项目启动时。似乎没有要设置一个自定义属性,我可以在解决方案级别指定当前解决方案的连接字符串名称(或键)的方式。
I have tried to put all my connection strings in the main application web.config, but I cannot find a way to reference the right one when the project starts. There doesn't seem to be a way to set a custom property where I can specify the current solution's connection string name (or key) at the solution level.
在这个任何意见或toughts?
我不介意改变我的项目结构,但重要的是,每一个客户都有自己的解决方案,使我们能够保持这种清洁和分离。
Any ideas or toughts on this?I don't mind changing my project structure, but it is important that every customer has it's own solution so we can keep this clean and separated.
推荐答案
我想,如果我是你,考虑主应用程序的基础创建的NuGet包。 (包的NuGet可保持完全私人的,所以你不必担心开放源码的要求...)
I would, if I were you, consider creating a NuGet package from your main application base. (NuGet packages can be kept entirely private, so you don't have to worry about open source requirements...)
通过一个包的NuGet,您可以复制DLL组件,ASPX文件,XML配置和几乎任何其他每个客户都需要有,只是通过安装包到客户的解决方案。您可以为每个用户在IIS中创建一个单独的虚拟目录(甚至是网站),他们都将拥有一切,他们需要运行。
With a NuGet package, you can copy dll assemblies, aspx files, xml configuration and virtually anything else each customer needs to have, just by installing the package into the customer's solution. You can create a separate virtual directory (or even web site) in IIS for each customer, and they will all have everything they need to run.
在最重要的是,你做这种方式获得的另一个非常重要的事情:可维护性。你可以在你的主要解决方案的新功能和bug修复工作,每当你想推的东西给客户的网站,你只需发布更新到的NuGet包。然后,您可以安装包更新到一个或所有用户特定的网站,但你不会在同一时间去做。如果一个客户站点需要滞后出于某种原因,它不从得到获得新的功能停止的其他客户
On top of that, you gain another very important thing by doing it this way: maintainability. You can keep working on new features and bug fixes in your main solution, and whenever you want to push something to the customer sites, you just publish an update to the NuGet package. Then you can install that package update into one or all of your customer specific sites, but you won't have to do it at the same time. If one customer site needs to lag behind for some reason, it doesn't stop the other customers from getting access to new features.
,它会带你到天堂的可维护性相比于一个解决方案,多在不同的解决方案,网站依赖从另一个解决方案,其中你甚至不能检查所有code,同时为编译错误...
Creating a NuGet package is easy, and it will take you to maintainability heaven compared to a solution where multiple sites in separate solutions depend on builds from yet another solution, where you can't even check all your code at the same time for compile errors...
这篇关于根据一个共同的基础应用多个ASP.NET web应用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!