I have a deployed WCF application running on IIS 7.5 as a site. One of the business dll's of that application (ABC.dll) has an application setting of type "connection-string".
I would like to change that DB connection string but can't find the right place to do it.
The ABC.dll.config in the Bin folder where the application dll's are deployed does not contain the actual connection string the application use at run-time.
How do I find that connection string?
If you have a WCF service running in IIS, you put the configuration in a web.config file in the root folder. This will contain all the settings that apply to your service. It is most likely that the connection string is being used from this file.
It is theoretically possible that if the settings are not in the web.config either, then they might be in the machine.config of the server on which you are hosting your WCF service. It is highly unlikely though that someone would store app-specific connection strings in this file but u never know sometimes.
Related
I have the basic blazor project that im trying to host in a specific way. I have managed to host the app in IIS where all the files were in the same folder. The issue im having is the web config in the root folder and then having the actual app itself in a subfolder.
IIS app file structure
im using blazor server which is sitting the "test" folder.
test folder where the blazor app is, seperate to the web config
Is this even possible to host in this way? or is there routing or config that needs to be done to get it to work?
Thanks,
So far I'm afraid it is unavailable to host application in site level. No matter I set the aspnet core handler in root level or folder level, change location value,change processPath. IIS just ignore the attribute even I have set it in both root level and folder level.
I think even you were able to host blazor in a sub-folder, Duplicate attribute verification is easy to crash the application when you need to publish something in root folder.
So the best way to handle this is convert test folder to an application. Then everything get isolated and start working.
interesting idea
I see no reason, why not to create a sub directory as website in iis. There have to be a extra app pool unmanaged for each.
I have An ASP.Net web site which reads data from an Access database, It works well, but after publishing it on IIS no data is retrieved.
I'm using the Web config to connect to database
<add name="GisDB" connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\AccessDB\Myacdb.mdb;Persist Security Info=False;" providerName="System.Data.OleDb"/>
You may have two specific issues to resolve:
1) IIS cant resolve the path of the Access Database
2) IIS may not be able to instantiate the ACE OLEDB drivers on the server.
A potential solution for 1) is to place the Access database in your /App_Data subfolder off the root of your website. You can specify a connectionstring in the web.config like this
Resolving 2) is trickier, especially if its a remote host. As a start, If using Visual Studio, compile your website binary into x86 mode and see if the problem persists. This could indicate a potential issue with the Access DLLs running on a 64 bit platform.
Almost certainly IIS worker process does not have rights to read files in the d:\AccessDB\ folder. Either grant it rights or move the MDB to an App_Data folder under your website root and change the Web.Config to suit.
I have a Windows Service that I'm creating and I'm wondering what options are available in order for me let developers configure the service.
The service is part of an over all larger open source project and hence the service is going to be installed on lots of different machines.
Normal I would use a web/app.config for this but I'm not sure if this is possible.
Hence I am looking to so how others handle this case.
you do as you expect. You use the app.config, which will be renamed to <exeName>.configwhen the project is built and then <exeName>.config will be read by the service called <exeName>.
Settings are applied in a layered way and may come from other configuration files on the machine, such as machine.config. You can read about how configuration is handled on MSDN
EDIT
In response to comment: A service will only read the config when it starts (for perf reasons). If you want to reload the config file later, you need to handle that yourself I think.
You could read the last modified date/time of the config file to determine if the file has been changed, or setup a file system watcher and then tell the configuration manager to reload that section again next time it is read, by calling ConfigurationManager.RefreshSection("appSettings") and that section will be reloaded from disk when you next access it. See the ConfigurationManager MSDN docs
You can just use a .config file with the same name as the exe that is the service.
If your service runs as MyService.exe, it's config file would be MyService.exe.config.
In Visual Studio, just add an Application Configuration file. This will add an app.config file to the project.
You can then access things like AppSettings and ConnectionStrings using the ConfigurationManager class, just like you do with ASP.Net applications.
I want to ask about the main considerations we have to put in mind when publishing application using SQLServer database?
I ask this question because I faced a problem when I developed an application using SQL server Database in C# and used it in another machine. The problem is an exception happen in launching the application.
This is the exception message:
<b>"The ConnectionString proberty has not been initialized"</b>. The ConnectionString is in App.config and assing while form loading.
This is the ConnectionString:
<b>"Data Source=.\SQLEXPRESS;Initial Catalog=test;Integrated Security=True;Pooling=False"</b> and it is in this file: appName.exe.config
The application is Desktop application and it's not need for installation just click .exe and it should connect to the existing SQLServer database with the ConncetionString in the appName.exe.config file.
The best way to deploy any type of application will be creating a setup.exe or .msi file.
Since this will ensure the important files which will copy to the target machine. It also provides a well structured file hierarchy along custom action which we can program each and every steps of installation.
It is always good to keep the connection properties in a config file, which helps to change the configuration settings without building the project. The exe will reads data from the config file, so if we changed the values then also it will works fine. While creating the setup project add the configuration settings and deploy or it is also good to have a common setup msi and different config files.
For example the database may be different for servers like DEV,QA,Staging etc. For each sever the msi will be same but the connection string will be different. So there is also a way to create self extracting files which will update the config files . For QA,DEV,Staging etc different self extracting files will be there. by running those files, it is possible to update the server details and authentication details. By providing msi and extracting files, users can install the application very easily
In my project I have a Windows Service and a WCF Service doing some actions on the same folder on a computer. The location of that folder will be given by the user within an app.config file that is included in the Windows Service project.
Now, I want the WCF Service to know the location of that folder (the folder given by the user), without the user having to type it into the WCF Service config file as well.
How would I go about doing that?
Thanks!
There are lots of possibilities here:
Add the path of the Windows Service's config file as a setting in the WCF service's config file, and use that path to read the file with an XML Reader.
Store the folder path in some centralized system, like a database or the registry, and have both services obtain the setting from that centralized placed.
Specify the path in each individual config file, but use a post build event to make sure they stay current. (For instance, maybe the post-build event retrieves the config setting from the DB and then writes it to the config file)
Have one service expose the configuration setting as a public service call. For instance, the WCF service could invoke a method on the Windows service to determine which path to process.
You can place it in the Machine.config, and both the WCF application and the Windows service can access it.
http://msdn.microsoft.com/en-us/library/ms229697(VS.71).aspx