从 IIS 更改 Global.asax 变量
我可以从 IIS 更改访问权限或编辑 Global.asax 中指定的值吗？原因是我没有源代码，我们现在需要的唯一更改是更改 Global.asax.vb 文件中指定的连接字符串（数据库）。
谢谢！！
Can I change access or edit the values specified in Global.asax from IIS?? The reason is that I don't have the source code and the only change we need right now is to change the connection strings (database) specified in Global.asax.vb file.
Thanks!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，正是出于这个原因，在 Web.config 中指定连接字符串。如果这些值是硬编码的，则除非可以更改代码，否则无法修改它们。您可以设置相同的数据库（名称、信用）并更改一些配置设置，以便您的数据库服务器解析为相同的计算机名称。我能想到的就只有这些了...
Usually, connection strings are specified in the Web.config for this very reason. If the values are hardcoded, there's no way for you to modify them unless you can change the code. You can setup an identical database (name, creds) and change some config settings so that your database server resolves to the same machine name. That's all I can think of...
好吧，我能够绕过这个问题。不是很优雅，可能会增加性能负载，但考虑到重新创建项目所涉及的工作，这是最简单的。
我创建了另一个 aspx 页面，并使用页面的 Page_Load 中的 Application 对象设置连接变量，然后对先前的默认文件执行了 response.redirect。我很幸运，因为所有代码都引用了应用程序对象，并且这仅在 Global.asax 中设置 - 如果有任何代码直接指定连接字符串 - 那么我就完蛋了！
唯一的开销是 Application_Start 只会被调用一次 - 但每次发出请求时都会调用 Page_Load 覆盖这些值。我准备做某种权衡。
我无法同意之前的答案，因为它提到了“理想”案例和最佳实践 - 它没有解决我的问题。如果之前的sql server能够完全降级的话，应该采用之前的方案。
谢谢你们！
Well, I was able to circumvent the issue. Not very elegant and might add to performance load, but was the simplest considering the work involved to recreate the project.
I created another aspx page and set the connection variables using the Application object in the Page's Page_Load, and then did a response.redirect to the previous default file. I was lucky as all code referred to the Application Object, and this was set only in Global.asax - had there been any code which directly specified the connection string - then I would be screwed!
The only overhead was that the Application_Start would be called only once - but overwriting those values with Page_Load will be called every time a request is made. Kind of trade-off I am ready to do.
I could not agree the previous answer as it mentioned the "Ideal" Case and the best practices - it did not solve my problem. The previous solution should be adopted if the previous sql server can be completely demoted.
Thanks Guys!