I have searched for other postings asking this same question. The typical answer is "use app.config instead".
All of the responses saying "use app.config instead" are useless. I do not want to read from app.config, I want read from web.config. If I wanted to read from app.config I would not have to be asking this question.
If you want to have a reason, I need a console app in order to be able to be scheduled for automatic execution. It must, however, share the same configuration as the web application that is installed on this machine. So stop trying to avoid the issue by saying "use app.config instead" and answer the question -- or come right out and say it is not possible.
Please, is there a way to access web.config (not app.config) from a console app?
I am currently using c# in visual studio 2008
Web.config is just an xml file. You can read anything form it using XmlDocument class. Load web.config into it and then use XPath query to find your connection strings.
Related
We're building a .net core web api application at the moment and so far it's been great to work with. However we have an issue with our deployment server (Team Studio) being unable to replace the DB connection string inside the appsettings.json file. Is it possible to solve this issue by putting the connection string in the old web.config format so that Team Services can do a replacement? I tried creating one but I'm unable to access the connection string from it using System.Configuration
The way appsettings.json is supposed to work is that it should only contain environment-neutral config. Anything specific to a particular environment, such as connection strings, should go into appsettings.{Environment}.json. That file is then loaded in based on the ASPNETCORE_ENVIRONMENT environment variable set on the server you're deploying to. In other words, you shouldn't need to replace anything. Just deploy both appsettings.json and appsettings.{Environment}.json and make sure that the ASPNETCORE_ENVIRONMENT variable is set appropriately.
Fortunately, web.config was removed from .net core. Only one thing that I can recommend is to create power shell script that will replace connection strings in your appsettings.json, and call it using team city agent.
I work on a team that works on a project. I change my project web config file to set a specific connection string but when I check-in or get latest version of project it changes to others connection strings. I have same problem in WCF Service references. appconfig and xsd files of service references always corrupted when I check-in or get latest version of program from tfs and I have to delete service references and add it again! How can I get rid of this?
We had the same issue on our project (with connection strings), and found a good solution: http://msdn.microsoft.com/en-us/library/ms254494(v=vs.110).aspx
By adding a connections.config file for each developer with his own connection string, we just needed to say that this file must not be a part of Source Control. Then in the web.config connectionString section, you just refer to the connections.config file.
Just be aware that you need to either transform your web.config or add the connections.config when publishing the site.
I know you can do the same about the appSettings section in the web.config.
How you do it with WCF, I don't know - but it sounds strange to me that your are not using the same WCF refence.
There are many solutions.
The team uses the same configuration (e.g. everyone uses localhost references)
You separate user from application settings (do not apply to all kind of settings nor projects)
Use transforms and solution configuration to map have per-environment setting
Use configSource to move config section in separate files that are not under version control
I do not think there is a perfect solution, but maybe you apply a mix of these. I strongly suggest to apply them in the stated order.
I have a website which is build in Classic ASP. This website has a web.config file. I never created it, and never knew Classic ASP sites could have a web.config file, but this might be from IIS7 to store settings there.
This website uses a C# class library (DLL) to do some stuff. But here comes the tricky part. Should the DLL be able to read the web.config of this website?
I've copied the configSections from my app.config (from within the solution) to the web.config from the site. And also copied some settings (connectionstrings and applicationsettings). But when I changed the connectionstring to a faulty one, it would just keep running without a problem.
When I placed the configsections on the bottom of my web.config, the website wouldn't load because of a faulty web.config, so I the webserver is doing something with it. But can a C# DLL read this file also eventhough it's not a .NET website?
Thanks in advance.
As Chris said, asp classic does not use it, so it must have been created by IIS7 (or someone putting it there as a joke). That its not used if confirmed by your changing settings having no effect.
When you copied sections, the file becomes an invalid config; it's probably that which is causing it not to run, though what's checking it I don't know.
Another possibility is that the ASP website is using a C# library via COM Interop, and the run-time is checking its validity when it starts.
I am currently updating a few settings in a rather large *.exe.config file via the *.exe executable by using XLinq to navigate the directories and read / write the values. The problem with updating this way is that changes only take effect after restarting the executable, but I would like the changes to take effect instantaneously. Is there a way to tell the executable to reload the *.exe.config file after I make the changes?
All help is appreciated and thanks in advance!
Exoskeleton for app.config
<configuration>
<system.serviceModel>
<!-- stuff... -->
<client>
<!-- this is the section I changed and want to have updated -->
</client>
</system.serviceModel>
</configuration>
EDIT: One of the reasons that I know so little on this subject is that I didn't create the app.config - it's auto-generated by somebody else's code. The reason that I have to change it and have the changes take effect in the application is that another part of the code (which I have no access to) calls on the config file to get its data, but if I don't reload the section then the old settings will be used, which won't work in this application.
EDIT2: If I can't change this dynamically, how do I change the code so that it can be done dynamically? Best answer gets the bounty...
var client =
System.ServiceModel.ChannelFactory<ISampleService>(
System.ServiceModel.Channels.Binding binding,
System.ServiceModel.EndpointAddress remoteAddress)
you can connect to a service also programmatically, and give the WCF directly the config needed.
with using this, you do not need the wcf config in the exe any more.
https://msdn.microsoft.com/en-us/library/ms576132.aspx
Settings with scope "User" can be easily stored and retrieved while the Application is running. If your settings are of scope "Application" I'm afraid you cannot modify and reload them without restarting your application. You'll need to roll your own configuration solution then.
There are 2 parts to making this work. 1) Updating the correct config file, and 2) forcing .net to reload the changes.
1) When a .net process starts, it will copy the existing .config to the vshost.exe.config file. If you update the original config file after the process has started, you will not see it in the vshost.config until you restart the process. So to make this work at runtime, you need to update the vshost.exe.config, not the exe.config file.
2) To force .net to reload the settings, you need to tell the configuration manager that the settings changed. You can do this with the ConfigurationManager.RefreshSection().
There is some more information and a couple code examples at: http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/3c365fdb-563e-4b0a-a4b4-df684c2dd908/
Basically, Microsoft designed it this way (having the configuration read at start up and not again), specifically to discourage you from trying this, because the *.config file live in the C:\Program Files folder, and that should not be writable by a non-Administrator.
I'm using Visual Studio 2008, developing a winforms app.
I have my database connection string stored in settings.settings.
My development and production environments require different database login credentials and right now I'm manually changing the connectionstring by hand before building for the 2 different environments.
Is there a better solution?
An eternal problem! :-)
Basically, right now, Microsoft doesn't really have a good answer for this.
What I would do is have both connection strings in my settings file, under two separate names, and then have a config setting in app.config which tells me which one to use:
MyDatabaseDEV = server=(local);database=mydatabase;-........
MyDatabasePROD = server=ProdServer;database=MyDatabase;........
and in app.config
<appSettings>
<add key="UseDatabase" value="MyDatabaseDEV" />
</appSettings>
This setting in app.config can be tweaked in your build process, e.g. by a "after build" batch file, or an MSBuild task or something, to be switched to "MyDAtabasePROD", when you do a production (release) build.
Microsoft promises us more and more flexible tools for .NET 4.0 / Visual Studio 2010, which should be out by the end of the year 2009. You should be able to create "config transformations" - check out these blog posts:
Web Deployment: Web.Config Transformation
ASP.NET 4.0 and Visual Studio 2010 Web Development Beta 1 Overview
Visual Studio 2010: Web.config transforms
Web.config Transformations with Visual Studio 2010
Marc
Where I work this is done by creating a folder called config that holds the various configurations.
source
config
MyProject
environment1
environment2
MyProject2
environment1
environment2
When the build script is run, it grabs the correct config based on which environment you're doing the build for...
you can make form asking the user to enter the connection parameters such as server name and database..., and store those parameters in Registry, files etc...
You should add an app.config file to your winform application. In this file store the connection string under the ConnectionStrings section.
In your code, when create a connection use that connection string using ConfigurationManager class to access config file.
So when you deploy your application, you have to chance the connection string once in config file and everything runs as expected!
You can defines your connections in settings, use dev connection in debug mode else production connection with #if directive.
//affect your prod connection here
#if DEBUG
//re affect your dev connection here;
#endif
A link to explain : http://msdn.microsoft.com/fr-fr/library/4y6tbswk.aspx
Right-click on the web site in the Solution Explorer and select Add Web Deployment Project.
Whenever this new WDP project is built, it will replace all the configuration elements you specify. You can also have different versions depending on Debug or Release builds. It works for almost all of the configuration options, including the connection string. There's lots of documentation on how to configure it correctly on the net, just search for "Web Deployment Project".
This is definitely the new "default" way to do this until MS decides to make it more formal in some future version of .Net/Visual Studio, if they ever do.
I've started using a setting called TestMode="dev|prod|uat".
The problem with compilation targets is that you can't change anything after build.
With this approach you can include all the connection strings and settings you need for all the environments you want. In your code configuration provider you can switch based on this setting.
With this approach all you have to do is change the flag once deployed or use deployment software like Octopus to change it for you.
I have given up with merging .config files which is difficult and error prone.