我感觉很蠢.
我已经创建了我的第一个ASP.net 4.0网站,经过多年的工作,从1.1以上开始.我们在machine.config级别有几个设置需要迁移到新的4.0 machine.config.我虽然已经将所需的连接字符串添加到以下两个文件的连接字符串部分:
当我在IIS中创建一个新网站并将其分配给ASP.net 4.0应用程序池时,我只获得默认的LocalSqlServer连接字符串.我尝试在上面的两个文件中编辑它的名称,以指示它所在的文件,但没有任何变化.
我应该看看其他位置的machine.config文件吗？
为我见过的 Asp.Net 配置 Process 模型，
这并没有给我明确的信息，我有一个场景-
我想为特定的 ASP.NET Web 服务配置自定义进程模型（如果需要，我会将它放在单独的应用程序池中），但 IIS 中的其他 Web 服务/站点应使用 machine.config 中存在的默认进程模型配置。
我的问题是，
是否可以在 web.config 中为特定的 ASP.NET Web 服务配置进程模型？
如果可能的话，我是否应该记住任何问题，并且在 Machine.Config 中使用 processmodel 的默认配置时，IIS 中的其他应用程序是否也会出现问题？
我最近决定将连接字符串移动到machine.config,因为这似乎是管理多个环境的最优雅方法.但是,如果需要(或者非开明群众开始抱怨),我仍然希望能够在我的本地web.config中覆盖这些设置.
如何在我的web.config中覆盖machine.config中的设置而不获取a,ConfigurationErrorsException因为该值已经设置？
我已经安装了一批新服务器,我终于尝试尽可能多地自动化进程.其中一部分包括对machine.config进行一些更改,比如在connectionStrings上设置configSource以及在lb池中设置机器密钥.
似乎在64位操作系统上,appcmd只影响Framework64目录中的配置,这在你运行32位应用程序之前就可以了.我需要在Framework和Framework64目录中更改配置.是否有一个秘密的参数(如/ commit:MACHINE32或其他东西),你可以用来告诉appcmd哪个配置搞乱？
我在一台Windows Server上有大约10个不同的.NET项目,主要是.NET 4.0,但有些是.NET 2.0
其中一些项目是asp.net,一些是后台实用程序/服务.
这些项目与我们基础架构中的100多个不同数据库进行交互.他们用来做的连接字符串每月至少更改几次.
这里的问题是忘记将ConnectionString放在其中一个项目中会导致很多问题,并且许多不同的程序员会一直将新项目/更新部署到服务器.
我对解决方案的新尝试是覆盖所有项目中的System.ConfigurationManager类,并将其替换为我自己的实现,该实现从我可以维护的共享配置文件中读取.然后我只需重新编译每个项目并进行部署.
我还可以尝试在所有项目之间共享的machine.config文件中维护ConnectionStrings,但是我必须为项目使用的每个版本的.NET框架执行此操作,该框架至少有三个,并且在这个文件好像很危险.
有人建议采用哪种方式进行？
谢谢.
我正在尝试创建一个将部署.NET托管数据提供程序的安装程序.为了使数据提供程序在应用程序下拉列表中显示为提供程序,我必须在machine.config的部分中添加提供程序:
<system.data>
<DbProviderFactories>
<add name="My Data Provider"
invariant="Sample.MyDataProvider"
description="My Data Provider"
type="Eli.Sample.MyDataProvider, Sample.MyDataProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5b9d34470b87a97f"
/>
</DbProviderFactories>
</system.data>
我该怎么做呢？只需一个指针就可以了.谢谢.
如果应用程序在.net 4.0上运行,那么获取.net 2.0 machine.config文件路径的最佳方法是什么？
一种方法是进行字符串操作和文件系统访问,用v2.0*替换v4.0*,
new ConfigurationFileMap().MachineConfigFilename;然后将其传递给ConfigurationManager.OpenMappedMachineConfiguration(new ConfigurationFileMap(<HERE>)).如果没有更好的可用性,我将采用这种解决方案.