I have several console applications and one MVC Web API application inside a folder. Is it possible for all these applications to refer to a constants.config file that resides in the parent folder?
In each of the Web.config files of all the applications, i have declared the config section as following:
<configSections>
<section name="Constants" type="System.Configuration.NameValueFileSectionHandler, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</configSections>
<Constants file="~/Constants.config">
But the Constants.config is not read by the applications. How to give the path correctly?
Related
In my windows service I have 2 web references
My windows service only contains an app.config not a web.config
my app config looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="MyFirstWindowsService.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
</startup>
<system.serviceModel>
<bindings />
<client />
</system.serviceModel>
<applicationSettings>
<MyFirstWindowsService.Properties.Settings>
<setting name="MyFirstWindowsService_postDataToMapicsWC_XAXSSTRN"
serializeAs="String">
<value>http://TESTDEV/web/services/XAXSSTRN.XAXSSTRNHttpSoap11Endpoint/</value>
</setting>
<setting name="MyFirstWindowsService_com_goodmanmfg_testdev_GETITMINFO"
serializeAs="String">
<value>http://TESTDEV/web/services/GETITMINFO.GETITMINFOHttpSoap11Endpoint/</value>
</setting>
</MyFirstWindowsService.Properties.Settings>
</applicationSettings>
</configuration>
[![enter image description here][1]][1]
the problem is my web services when i click on them the URL field is still saying
"Web reference URL" http://PROD/web/services/XAXSSTRN.XAXSSTRNHttpSoap11Endpoint
[![enter image description here][2]][2]
what is the end goal? To release this windows service to dev and prod environments without having to rebuild the entire solution.
The ideal behavior is :
Build the latest code in dev mode (test it, if all test good then , step 2)
Provide an app.config file with prod urls to dropped inside the
folder
Release
As you can see what I am trying to avoid is the need of dropping the file manually changing those 2 web services , rebuilding the solution AND THEN releasing...
Classic ASP.NET apps get their configuration from a hierarchy of web.config values. Other apps (console applications, Windows Forms apps, WPF, Services, ...) get their configuration from a configuration file named [NameOfExe].exe.config (and occasionally from [NameOfAssembly].dll.config. That file is located in the same folder as the exe itself.
For example, if your service is MyWcfService.exe, you will very likely find a MyWcfService.exe.config file in the same folder (for example, in the bin/debug folder). Its contents should be the same as your app.config.
Visual Studio makes this all "just work" by creating an app.config file in your source folder and then, at build time, copying the contents of that file to the appropriately named [NameOfExe].exe.config file in the same folder as the EXE.
In the normal case, you might have one set of URLs (and perhaps other data) for your dev environment, another for QA, another for Integration Test and another for Prod. You can manage this through the use of configuration transforms.
I think this goes some way towards answering your questions. In summary
App.config files have nearly the same capabilities as web.config
files
App.config files get "compiled" to [NameOfExe].exe.config
files at build time and placed in the same folder at the EXE
Configuration transforms may help you out with managing your URLs
Your other choice is managing a set of [NameOfExe].exe.[Environment].config files and manually putting them in the right place.
We use app.config to store user settings, but changed the name of the exe... for reasons. I need to be able to upgrade the settings from version 1.4 called name1.exe to version 1.5 now called name2.exe.
I've tried several methods, the first was to add code in Program.cs Main() where it would use System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath to find the path where the new settings file should go, and search the base path of that setting to find the 1.4 version under the old name, then copy the 1.4 folder into the correct part of the path where the Properties.Settings.Default.Upgrade() would work like normal.
I've also tried replacing the new app.config file with the old one and calling Properties.Settings.Default.Reload(); and doing the same but just restarting the application.
Each of those methods worked, even in release mode outside the ide. But we also use SmartAssembly to merge some other dlls into our exe's assembly. Smart assembly must do some unknown magic, because it doesn't work after being SmartAssembled.
If I manually copy the old settings to the new location (replacing the app.config) then try to run my app doens't even start, it must crash right away. Again, only after using SmartAssembly to merge our dlls. I've narrowed the crashing down to this part in the xml...
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="userSettings">
<section name="DllNameA.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
<section name="DllNameB.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
<section name="ExeName.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
That last part of the xml "section name=ExeName.Properties.Settings..."
was not there in the old settings file. I'm not sure why it's added now, but it works if I manually add it to the old settings file when copying it over.
Is there a way to make this work?
This probably isn't the right way to do this, but I did just edit the xml to add the missing section and it is working.
We are trying to create a WCF web service which will connect to SQL Server using Entity Framework. The WCF Service will be deployed on SharePoint 2013 mapped to ISAPI folder on SharePoint hive.
We are able to deploy the solution in SharePoint 2013 server, but whenever we call the web service it returns error as below
System.IO.FileNotFoundException: Could not load file or assembly
'EntityFramework, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=XXXX' or one of its dependencies. The system cannot
find the file specified.\u000d\u000a File name: 'EntityFramework,
Version=6.0.0.0, Culture=neutral, PublicKeyToken=XXXX'\u000d\u000a
at ()\u000d\u000a at \u000d\u000a\u000d\u000a"
In App.Config file we have below code.
<configuration>
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
...
</configSections>
<configuration>
We created a simple console application on same SharePoint 2013 server and the code ran successfully.
What are we missing here?
The problem was that the entity framework DLL needed to be present in the GAC. Despite being present in the SharePoint solution, it was not referring to it.
We added entity framework DLLs to GAC and it has now started working.
I added a app config file to C# project and wanted to store config for log4Net and some basic app setting. The generated app.config file is empty.
I looked at other projects. They had an applicationSettings section. So I added a applicationSettings section; by copy pasting from some other project. Then I did not understand what some of the attributes were; like the PublicKeyToken b77a5c561934e089. I tried searching to see if the section is automatically generated; could not find how. The online resources point to complicated schemes about writing your own config class. My needs are far simple. Online resources do not document the attributes per se.
So short of copy pasting from some other project, how do you get around to adding this section?
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="CrawlReponseHandler.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
</sectionGroup>
The section is added automatically by going to project -> properties -> settings tab and adding the properties.
Let's say we have Assembly1 and Assembly2.
Assembly2 is a C# class library used by Assembly1.
Web and Service References are configured and stored in Asembly2/app.Config.
Moreover, the EF connection string(s) are in Assembly2/app.Config.
When I use Assembly2 in Assembly1, the Assembly2 config file is not used. In fact, in that scenario, only the Assembly1 configuration appears accessible through default means.
As a result, I have to copy the Assembly2 config contents into the Assembly1 config.
This has worked for me for many projects.
Is there another way? A better way?
It seems wrong to have repeating configuration data.
Do you have a recommendation or technique that works?
Thank you.
You need to apply changes to the config file of entry point exe assembly. Class library assembly (dll) config files are never used. They are made by Visual Studio so you could easily copy the settings to exe config files if needed.
Bellow is example of the config file for exe assembly that has both, settings from class library ClassLibrary1 and settings from the exe assembly MainAssembly. You can see that both connection strings are in one connectionStrings settings. However, if you need to set other settings, beside connection string, you need to add extra section.
If you are already using this technique, this is correct way to go. This technique is flexible. For example if you have more than one project having the same connection strings on one box, you could specify the connection strings in machine.config file. You can also override the settings in some projects if needed.
<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings"
type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<!--This section declaratrion pasted here from dll conifg file -->
<section name="ClassLibrary1.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
<!--This section declaratrion was here in the first place -->
<section name="MainAssembly.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
</sectionGroup>
</configSections>
<connectionStrings>
<!--This connection string was here in the first place -->
<add name="MainAssembly.Properties.Settings.MainAssemblyConnectionString"
connectionString="MainConnectionStringValue" />
<!--This connection string pasted here from dll config file -->
<add name="ClassLibrary1.Properties.Settings.LibraryConnectionString"
connectionString="LibraryConnectionStringValue"
providerName="" />
</connectionStrings>
<applicationSettings>
<!--This settings section pasted here from dll config file -->
<ClassLibrary1.Properties.Settings>
<setting name="LibrarySetting"
serializeAs="String">
<value>LibrarySettingValue</value>
</setting>
</ClassLibrary1.Properties.Settings>
<!--This strings section was here in the first place -->
<MainAssembly.Properties.Settings>
<setting name="MainAssemblySetting"
serializeAs="String">
<value>MainSettingValue</value>
</setting>
</MainAssembly.Properties.Settings>
</applicationSettings>
</configuration>
A DLL (or another referenced assembly) is not meant to carry it's own app.config, but rather have everything configured by the caller. So everything should go into the app.config of the exe.
Consider for example a shared data access library that needs connection strings to the database. The library should be possible to use from a variety of applications with different connection requirements. Having the connection string tied strictly to the shared library wouldn't work, it has to be done at the client using the library.
It is possible to put systemwide settings that affect all applications running on a machine in the machine.config file, but use that approach with caution as it will affect all applications on the machine.