10

我们有一个在 IIS 服务器上运行的旧版 ASP.net 支持的站点，该站点由一个中心团队开发，并被多个客户使用。然而，每个客户都有自己的站点 aspx 文件副本和 web.config 文件。这会导致问题，因为善意的支持工程师对源 aspx 文件的副本所做的更改没有被折叠回中央源，因此我们的代码库出现了分歧。我们当前的文件夹结构类似于：OurApp/Source aspx & default web.config
Customer1/Source aspx & web.config
Customer2/Source aspx & web.config
Customer3/Source aspx & web.config
Customer4/Source aspx & web.config
。 ..

这是我想改变的，每个客户只有一个定制的 web.config 文件，所有客户共享一组通用的源文件。类似于：OurApp/Source aspx & default web.config
Customer1/web.config
Customer2/web.config
Customer3/web.config
Customer4/web.config
...

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

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

4

7 回答 7

6

如果您在单个应用程序实例上死心塌地，您可以在单个 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 而不必担心哪个客户正在访问该应用程序。

于 2008-11-28T03:57:43.177 回答
2

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

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

您应该考虑更改您的流程，以便在随处部署后进行更改。从长远来看，这将使您的一切变得容易得多。

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

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

于 2008-11-28T02:48:11.537 回答
1

使用外部源代码控制应用程序并根据需要不断推出更新。

无论如何，让支持工程师实时更新您的实时站点并不是一个好主意。

于 2008-11-28T02:12:03.937 回答
0

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

于 2008-11-28T03:15:40.577 回答
0

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

首先，虽然我不知道您的独特情况，但我通常会敦促您继续单独安装。它通常允许更大的灵活性。在我脑海中浮现：您是否会进行自定义，或者不同的客户端运行不同的版本？你确定吗？在这里保持灵活性的最简单方法是继续进行单独安装。

在我看来，如果您的做法正确对齐，那一点也不难看。根据您提到的一些事情，您在该领域遇到了麻烦 - 显然，可能存在源代码控制购买/培训问题。但你知道这一点。我还会仔细研究您的部署程序等。我有一种感觉，你可能在这方面还有其他问题，我的意思是绝对没有冒犯。

也就是说，假设您想继续前进。

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

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

确实，这种情况的明显优雅几乎总是被它引入的挑战所抵消。如果我仔细考虑过，我可能会通过引入另一个智能管理连接字符串的数据库来解决这个问题，或者可能会钻研将所有登录信息直接保存在 web.config 中（这是可能的，但......不理想） ，但是我的直觉说这项工作将被浪费，因为有一天你最终会回到你现在的工作方式。

另外：直接在生产中更改代码显然不是这里的最佳实践。但是，如果您在一个拥有任何流量的单一共享平台上，那将永远不会发生。深思熟虑。

如果我遗漏了什么，请告诉我！

于 2008-11-28T04:06:36.683 回答
0

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

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

于 2008-11-29T20:00:38.867 回答
0

正如我们所说，我正在实施这一点。

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

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

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

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

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

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

于 2009-01-16T02:05:16.820 回答