ASP.Net MVC 2 中的多个环境
我正在学习 ASP.Net MVC 2，有 PHP 和一些 Rails 背景，对我来说唯一不喜欢的事情之一是管理配置设置（如连接字符串或外部服务端点）的方式。
我以前的公司使用的 PHP 框架有配置文件的标准格式和约定。我的公司能够利用这一点来实现，以便根据环境变量（在 Apache 配置中设置）加载不同的配置文件。这使得根据环境更改任何配置设置变得非常简单和自动。据我所知，Rails 内置了此功能的某些版本。
我熟悉 .Net 世界的 app.config 和 web.config 文件，但是有没有办法根据环境进行这些更改，最好是自动更改，并具有不同的粒度级别？与我习惯的相比，整个配置系统似乎非常贫乏。
我可能可以将一些东西组合在一起来实现这一点，但我想看看人们在实践中采取了什么方法，或者人们是否正在使用一些标准工具。
I am learning ASP.Net MVC 2, coming from a PHP and some Rails background, and one of the only things that seems off to me is the way you manage config settings like connection strings, or endpoints for external services.
With the PHP framework my previous company used there was a standard format and convention for config files. My company was able to leverage this to make it so that a different config file would be loaded based on an environmental variable (which was set in the Apache config). This made it very simple and automatic to change any config setting based on the environment. As far as I know, Rails has some version of this functionality built-in.
I am familiar with the app.config and web.config files of the .Net world, but is there a way to have these change based on the environment, preferably automatically, and with various levels of granularity? The whole config system seems very anemic compared to what I'm used to.
I could probably hack something together to accomplish this, but I wanted to see what approach people are taking in practice, or if there's some standard tool people are using.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
有 web.config转换。
我可能是错的，但我似乎记得，如果只是使用 Visual Studio 中的“开始调试 (F5)”按钮启动应用程序，它们就不会被应用，这使得该功能对于很多用途来说似乎不切实际。
There is web.config transformations.
I am likely wrong, but I seem to recall that they wouldn't get applied if one simply started the application with the "Start Debugging (F5)" button inside Visual Studio, making the feature seem impractical for a lot of uses.
您可以尝试这样的操作：使用预构建事件管理多个配置文件环境
You could try something like this: Managing Multiple Configuration File Environments with Pre-Build Events
显然，您可以在“调试”与“发布”模式下运行您的环境。 Rails 中的
ENV变量和 PHP 中的类似约定显然是它们的优势之一。与任何选择一样，总会有一个权衡，这就是其中之一。当我在 Rails 中时，我可以欣赏使用适当的 gem 等加载ENV变量（测试、开发、生产...）的能力。这很棒。当我在 Rails 中时，VS intellisense 之间也有相当大的差异，可能是最好的。也就是说，我见过的一些技巧是将 MachineName 属性编码为适当的连接字符串等，以便 WebConfig 可以轻松地在不同的开发人员和服务器等之间传递......
Obviously, you can run your in environment in "Debug" vs "Release" mode. The
ENVvariable in Rails and similar conventions in PHP are clearly one of their strengths. As with any choice theres always a trade off and thats one of them. When I'm in rails I can appreciate the ability to load up yourENVvariable (test, dev, production...) with the appropriate gems and such. Its great. When I'm in rails, theres also a considerable difference between VS intellisense, probably the best thats out there.That said, some tricks I've seen have been coding in MachineName properties into appropriate connection strings and the like so WebConfigs can easily be passed between different developers and servers etc...
我个人使用 machine.config 来管理特定于环境的设置。该文件包含机器特定的设置。
如果您没有为每个环境配备专用计算机，而是在 IIS 中使用不同的网站，则可以在每个网站的根目录中放置一个根 web.config 文件，其中包含特定于环境的设置。
基本上在这个全局配置文件中，我存储包含 SQL Server、Web 服务服务器的名称的键/值对...这些名称因环境而异，然后在我的应用程序中，我使用这些键来构造最终的连接字符串、http Web 地址，...
一旦这些全局配置设置就位，您就可以在所有环境中使用 web.config 部署完全相同的应用程序文件。
Personally I use machine.config to manage environment specific settings. This file contains machine specific settings.
If you don't have dedicated machines for each environment but instead you are using different web sites in IIS you could have a root web.config file located at the root of each web site containing environment specific settings.
Basically inside this global configuration file I store key/value pairs containing the names of my SQL Server, Web services server, ... which vary across environments and then in my application I use those keys to construct the final connections strings, http web addresses, ...
Once those global configuration settings are in place you can deploy the exact same application files with web.config among all environments.