Question

我们有一个在IIS服务器上运行的传统ASP.net驱动的站点，该站点由中央团队开发，并由多个客户使用。但是，每个客户都有自己的站点的aspx文件副本和web.config文件。这导致了问题，因为良好意义的支持工程师对源aspx文件的副本所做的更改没有被折叠回中央源，因此我们的代码库是分歧的。我们当前的文件夹结构类似于： OurApp / Source aspx＆amp;默认的web.config
Customer1 / Source aspx＆amp; web.config中
Customer2 / Source aspx＆amp; web.config中
Customer3 / Source aspx＆amp; web.config中
Customer4 / Source aspx＆amp; web.config中
...

我想改为每个客户只有一个自定义的web.config文件，并且所有客户共享一组通用的源文件。所以类似于： OurApp / Source aspx＆amp;默认的web.config
customer1表/ web.config中
顾客2 / web.config中
Customer3 / web.config中
Customer4 / web.config中
...

所以我的问题是，我该如何设置呢？我是ASP.net和IIS的新手，因为我通常在家里使用php和apache，但我们在这里使用ASP.net和ISS。

使用源代码控制，我打算重新培训支持工程师，但有没有办法避免拥有源aspx文件的多个副本？我讨厌那种重复！

Answer 1

如果您在单个应用程序实例上设置了死机，则可以在单个web.config中使用自定义ConfigurationSection后完成所需的操作。有关基础知识，请参阅：

示例XML可能是：

<YourCustomConfigSection>
   <Customers>
     <Customer Name="Customer1" SomeSetting="A" Another="1" />
     <Customer Name="Customer2" SomeSetting="B" Another="2" />
     <Customer Name="Customer3" SomeSetting="C" Another="3" />
   </Customers>
</YourCustomConfigSection>

现在在ConfigSection属性中，公开Name，SomeSetting和Another。访问或设置属性时，请使用条件（请求域或其他唯一标识客户的内容）来决定使用哪个。

通过正确实施，应用程序开发人员无需了解幕后发生的事情。他们只使用CustomSettings.Settings.SomeSetting，而不用担心哪个客户正在访问该应用。

Answer 2

我知道这看起来很烦人，但重复实际上是一件好事。这里的问题是您的过程，而不是系统的设置方式。

保持网站分离实际上是一件好事。虽然它看起来像“重复”，但实际上并非如此。这是分离。应积极阻止您的支持工程师对生产代码进行更改。

一旦到处部署，您应该考虑更改流程以进行更改。从长远来看，这将使您的一切变得更加轻松。

要真正回答你的问题，答案是否定的，你不能这样做。原因是web.config不是为存储用户级别设置而设计的，它旨在存储每个应用程序实例设置。在您的情况下，每个用户需要一个应用程序实例，这意味着单独的配置文件。

为了使您的系统正常工作，您需要能够抢先告诉应用程序使用哪个配置文件，如果没有用户的某种输入，这是不可能的。

Answer 3

使用外部源代码管理应用程序，并根据需要继续推出更新。

让支持工程师实时更新您的实时网站并不是一个好主意。

Answer 4

好吧，你可以尝试使用硬链接： http://msdn.microsoft.com/en-us/library/aa365006.aspx ......你问了。

可能感兴趣的另一个问题： Techniques For Distributing ASP.NET User Controls Across Projects

Answer 5

根据Web配置中的实际内容以及客户之间的设置不同，您可以选择使用单个Web配置，并将其他客户特定的配置选项存储在数据库或其他一些自定义xml /文本文件中。只要web.config中的特定客户设置不必对IIS的操作方式执行任何操作，并且您只是使用它来存储值，那么此解决方案可能对您有用。

Answer 6

如果我理解正确，听起来你有多个部署（每个客户端一个），唯一的区别是web.config，对吧？

首先，虽然我不知道您的独特情况，但我一般会建议您分开安装。它通常允许更多的灵活性。在我的头脑中：您是否会进行自定义，或者运行不同版本的不同客户？你确定吗？保持灵活性的最简单方法是继续单独安装。

在我看来，如果你的做法正确对齐，那就不难看了。基于你提到的一些事情，你在这方面遇到了麻烦 - 显然，可能的源控制买入/培训问题。但你知道这一点。我还会仔细研究你的部署程序等等。我觉得你可能在这方面有进一步的问题，我的意思是绝对没有冒犯。

那就是说，让我们说你想继续前进。

您没有说明所有客户端是否共享一个公共数据库，但我不这么认为，因为设计这种类型的系统通常不值得额外的复杂性（在任何规模的系统中都可能很严重）所以人们经常选择将它们分开。

这意味着您已将连接字符串存储在某处。通常那将是web.config ......所以这似乎打破了我们的计划。

真的，这种情况的明显优雅几乎总是被其引入的挑战所抵消。如果我考虑得足够困难，我可以通过引入另一个智能管理连接字符串的数据库或者直接在web.config中直接保存所有登录信息来找到解决方法（这可能但是......不理想）然而，我的直觉说这项工作将被浪费，因为有一天你会回到现在的状态。

另外：直接在生产中更改代码显然不是最佳实践。但是，如果您处于具有任何流量的单一共享平台上，那么这种情况永远不会发生。值得深思。

如果我错过了什么，请告诉我！

Answer 7

再次感谢大家的回答。阅读完它们并仔细思考我认为我将要做的就是暂时保留多个实例，我将首先尝试改进我们的更新过程。然后我将开发一个新版本的应用程序，它在数据库层中包含用户配置信息，然后根据某人建议的请求域或URL选择用户。这样我可以让一个应用程序实例干净地支持多个不同的客户端配置。

由于大多数客户端配置数据确实与表示或数据源相关，因此没有什么复杂的。我认为我们最终得到了多个应用程序实例，主要是因为原来的程序员并没有期待多个客户并且没有为此设计，所以当有人出现并添加第二个客户时他们只是复制了应用程序，这对每个实例都是浪费的与原始版本大约99.99％相同。

Answer 8

我正在实施这一点。

在主web.config中，每个安装我有1个项目。它指向我为每个客户端（以及自定义母版页，CSS，图像等）构建的自定义配置文件。

使用WebConfigurationManager.OpenWebConfiguration，我在其子目录中打开新的webconfigs。我通过使用System.Web.HttpContext.Current.Request.Url.OriginalString确定使用哪一个，并确定调用我的uRL。基于该URL，我知道要使用哪个web.config。

从那时起，客户端都使用相同的代码库。他们也有自己的数据库。

当我们进行更新时，必须更新30-40个安装的想法吓到了我的死亡。我们不想支持30-40个代码库，因此除了母版页，css和图像之外不会进行自定义。

我编写了一个自定义类库，它知道如何切换到正确的webconfig，并阅读我使用所有设置构建的自定义部分。

我现在唯一的问题是FormsAuthentication Cookie。我也需要能够切换它。不幸的是，该名称的属性是只读的

具有多个实例的单个ASP.net站点＆amp; web.configs

8 个答案: