I am working on a asp.net application that stores important data in app.config. In all Windows versions before Windows 10, the tests correctly load the data I want, but once I upgraded a system to Windows 10, the application no longer is able to pass the same test and fails to grab data. Whenever it read from the app.config file, as seen in the code below, Null is always returned.\
var data = System.Configuration.ConfigurationManager.AppSettings["PathName"];
When run in Windows 8, the value returned is a valid string that I use. When run in Windows 10, null is returned despite the file being present just as before. Once the value is used later on in regards to path3, an Exception is tripped and the error shown below occurs. Path3 comes from a function that the Null value is passed into.
threw exception: System.ArgumentNullException: Value cannot be null. Parameter name: path3
I have tried changing user permissions to files, folder and so on, but nothing seems to change this. I have also changed the User Account Control settings with no luck. I am using Visual Studios 2013 Professional and always run it in under admin mode.
Everything I have looked at online has not helped much and pretty much reiterates most of the steps I have already tried. Any insight is greatly appreciated.
Contents of app.config (Key = "PathName")
<?xml version="1.0"?>
<configuration>
<configSections>
</configSections>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
<appSettings>
<add key="PathName" value="DATA_VALUE_NEEDED" />
</appSettings>
<applicationSettings>
</applicationSettings>
</configuration>
So, after trying a lot of solutions, I finally figured out what was creating the problem. I'm not exactly sure why this occurred, but this is what happened all the same.
On windows 8, the app.config file from test projects loads directly from the main project it is meant for. Meaning, if you create a separate project for your tests, it links to the original that it was created for when loading app.config files.
In Windows 10, this does not seem to be the case for some reason. For some reason, the app.config file being read in was not the one for the project the tests were created for. It was some sort of auto generated default despite no settings or configurations being changed between porting the code between the two OS versions.
I was able to solve the problem by copying the file directly from the main project into the test project for it. Then, with a link between the two, they will stay updated when either one is changed.
I still don't understand why this happened and cannot locate the generated app.config file. After debugging, I simply noticed that the loaded key value pairs available did not exist in any single XML files in the entire project repository. Hopefully this helps others down the road with the same problem since I have seen several other reports online of people running into what seems to be this problem. Thanks everybody for your help!
Related
I've got a VS 2013 c# (.NET 4.5) solution with 10 projects.
2 of them (the presentation one and a web service -WCF-) have similar config options:
Web.config with
<configSections>
<section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
</configSections>
and
<unity configSource="Unity.xml" />
And a Unity.xml with Unity configuration, identical in both projects.
When I start the solution (I've tried to start both projects or just the WS) the presentation project starts well but the WS is not able to add a service, triggering the message:
The configSource file 'Unity.xml' is also used in a parent, this is not allowed.
If I delete the <unity configSource="Unity.xml" /> line the services are added, but obviously the application doesn't work because I don't have the persistence access.
Any idea? Can I share more relevant data?
I'm deploying in IIS Express.
BTW, the project worked some weeks ago. Something must have changed, but I've got no idea of what, because I've been working with other solutions meanwhile, not this.
I'm a bit lost... As you can see :)
Thanks!
Edit: I forgot to say that the same project downloaded from TFS in a different machine works fine. I has to be something with my machine, but no idea of what...
Well, no way to solve it.
I've completely replaced the solution with the TFS latest version, I've put the WS project inside the Presentation project (they used the same backend anyway) and, after some configuration work, it works fine.
I'm not able to guess which problem was with the Unity.xml...
While compiling my application (ASP.NET, C#), i set compilation debug="false" in Web.config
to improve the performance and published it upon development machine, It was working fine at development machine.
But when i moved the these compiled files to Hosting Server, Application showed me this exception
an item with the same key has already been added
Since this was the only change i made, i changed the attribute like "debug=true" and system started working fine at hosting machine.
But i don't want to keep debug=true because of performance issues caused by this attribute.
Please share your experience if anybody faced similar situation.
You could try deleting the debug attribute altogether, the default is false.
You should also check to see if there are any other web.config files present in the parent folders of where you are publishing the web application. If so are they required?
Hope this points you in the right direction.
I have been running into this issue for quite some time. It occurs when I open up an asp.net page pointing to my localhost. I am running windows 2008 r2 with visual studio 2012 and iis 7.5.
The config source that it shows is this. :
1451: <remove name="ASP.NET_4.0.30319.0" />
1452: <filter name="ASP.Net_4.0_64bit" path="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_filter.dll" enableCache="true" preCondition="runtimeVersionv4.0,bitness64" />
1453: <filter name="ASP.Net_4.0_32bit" path="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll" enableCache="true" preCondition="runtimeVersionv4.0,bitness32" />
It shows it is erroring on line 1452.
Initially, it was an issue in the applicationHost.config file in the inetsrv 32 and 64bit locations. I went in and removed the duplicate 4.0 entry and it worked for a good couple of months.
It then started throwing this error again. At that time I just did a full re-install of IIS and my application started working again.
Once again this error has started to occur, I once again performed a full reinstall of IIS but this time that does not help and my applications continue to error due to this duplicate collection error.
I believe this all stems from an ISAPI issue I had long long ago prior to all of this which is detailed here. :
http://weblog.west-wind.com/posts/2011/Apr/04/Error-on-64-Bit-Install-of-IIS-LoadLibraryEx-failed-on-aspnetfilterdll
Really, I wondering if anyone else has seen this. Where I am really confused is if I look at the temp applicationHost.config file in the inetpub/temp/appPools location (this is the file that the application running is referencing and erroring on). The problem I have with this is that the current temp applicationHost.config that is being used by the application differs from the one found in the inteserv locations in that it has the ASP.NET_4.0.30319.0 line which is causing the error. The confusion is that this line causing the error has to be coming from some where but I cannot find it in the inetsrv locations or in the app pool locations, hence my confusion.
I would assume that this must have been resolved for most, but in case if anyone still has this problem -
I am having VS 2017 and i had this issue in the past on 2015. Later when i setup 2017, i see this nice little option that i believe resolved mine. And i hope it may even solve yours. Give a try.
And using IIS Express, refer to this
screenshot of Web project properties showing the tiny little settings
In my case, being 64 bit OS, i had to set the x64 explicitly (on the bitness field). Having it as Default or x86 didnt had my mvc app run.
I received this error a week ago on a Visual Studio 2010 project. I found this thread and it had the correct solution. I had to download the 2007 access database engine and I no longer received this error.
This week, I am doing a new project and received the exact same error. On the old project, I did not. I uninstalled the program that was downloaded to originally get it to work. Tried both projects, neither one worked, which is what should happen. Restarted computer, installed program again, then restarted computer again. I tried the new project where it wasn't working and it still didn't work. Tried the old one, it still worked.
So I went back to the thread and noticed that in step two he says "in VS click add data source, follow the wizard." I had not done this to get it to work with my first project. So I tried it out, but I still receive the error. Odds are, I didn't do it correctly, so if I get help here, that would be great. I will detail out the steps I originally did where it didn't work.
Go to data and then add new data source
Select database, hit next
Select dataset, hit next
New connection > Browse for database file > blank username and password > Hit ok > hit next
A prompt appears saying "The connection you selected uses a local data file that is not in the current project. Would you like to copy the file to your project and modify the connection? If you copy the data file to your project, it will be copied to the project's output directory each time you run the application. Press F1 for information on controlling this behavior." > Select Yes
"Do you want to save the connection string to the application configuration file?" > Yes, save file as DBConnectionString > select next
"What database objects do you want to use in your dataset?" > I selected the only two tables that I am using in this project > finish
I would just like to say that for my first, working project, the database is just in my folder, not actually added in the project and it works. For step 5 above, I have selected yes and no for adding the datafile to my project. Either way, it doesn't work and even if I say no, it still adds the files to my project.
Sorry for the long response. Thought it would be helpful to have all the detail. Any help appreciated.
5.
I cannot explain why, but it is working now.
I removed the process of adding the data source; I didn't need it. I have an application configuration file that configurations the settings and such. I removed this code, copied the code from my old one, then saved it in the new project. I saved the project. I ran it and now the problem was gone.
The code was exactly the same, so I don't understand why. It appears though that there was a problem with my SQL statement. It's as if the error message for this wasn't being displayed and for some reason the error message mentioned above was instead. I don't understand it, but it works now and I did virtually nothing.
If you have no idea what config file I'm referring to, the code for mine is below.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key ="DBConnectionString"
value = "Provider = Microsoft.ACE.OLEDB.12.0; Password = ; User ID = ; Data Source = "/>
</appSettings>
</configuration>
There are known issues with MDAC and build targets, for example, if you are on a 64bit machine and your project targets x86, you must install the MDAC for x86, but if you target Any CPU, then you need the x64 version installed. If your project was never built, there may be an issue with the system determining which version of MDAC is going to be required. When in doubt, you probably should just install both the x86 and x64 versions on your machine, just to be safe. MDAC 2010 can be found here.
I recently wrote a DLL in C# (.Net 2.0) which contains a class that requires an IP address. A co-worker of mine altered the class to retrieve the IP from a ".dll.config" (XML) file -- This apparently is automatically generated by the "Application Settings" file he created (Settings1.settings). The benefit of this was to allow the end-user to change the IP address in the XML/config file at will.
Unfortunately, when I check his code out of the tree and try to compile (or use) this new code, any application calling this DLL only gets the default value, rather than the value from the file.
The constructor that calls the config file looks like this:
public class form : System.Windows.Forms.Form
{
public form()
{
// This call is required by the Windows Form Designer.
InitializeComponent();
IP = IPAddress.Parse(Settings1.Default.IPAddress);
}
}
I found a reference to this problem on the MSDN forums where a user said:
the 'old' values (the ones you define at development time) are hard coded. If the franework isn't able to access or open the config file it will use the defaults instead. This will always happen if you use settings in a dll.
Does this mean that I cannot store an external value for a DLL in a config file? (My co-worker has somehow made this work...)
Since my framework appears to be unable to access or open the config file, how do I figure out why it's failing? Or even detect when this happens?
Decker: That helps a bit. Unfortunately, I am writing this DLL to a specification, so I don't actually have access to the Application's config file. As you'll note above, my co-worker created a "Settings1.settings" file. I didn't understand this at the time, but it seems now that adding the "1" keeps it out of the settings space of any application that calls it.
I guess what I'm trying to figure out is why the DLL doesn't seem to find the config file sitting next to it in the same directory. Tracing thru the code step-by-step reveals nothing.
As an aside, I can change the "Output Type" of my assembly from "Class Library" to "Windows Application" and add the following lines at the beginning of my DLL code:
[STAThread]
public static void Main(string[] args)
{
System.Windows.Forms.Application.Run(new form());
}
When I run this, it generates a different config file (a ".exe.config") and that one I can alter and have it pull the new data from the file. So I'm a bit confused. Any ideas?
I use this technique all time time. Often I have a library assembly that requires certain settings, and I need them set both by testing projects as well as the primary "executable" assemblies -- be they web projects or Windows service projects.
You're correct in that when you create a settings file for any project, it adds an application config file. The value you enter for any setting is stored in two places -- the config file AND in attributes on the classes created by the settings infrastructure. When a config file is not found, the values embedded in the attributes are used.
Here is a snippet that shows such an attribute:
Here is a snippet that shows the default value of the ConcordanceServicesEndpointName in the generated class:
[global::System.Configuration.ApplicationScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("InternalTCP")]
public string ConcordanceServicesEndpointName {
get {
return ((string)(this["ConcordanceServicesEndpointName"]));
}
}
What you want to do is copy the configuration section out of the app.config file from the library assembly project and merge it (carefully) into the applicable web.config or app.config for the main assembly. At runtime, that's the only config file that is used.
Here is an example:
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="LitigationPortal.Documents.BLL.DocumentsBLLSettings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<applicationSettings>
<LitigationPortal.Documents.BLL.DocumentsBLLSettings>
<setting name="ConcordanceServicesEndpointName" serializeAs="String">
<value>InternalTCP</value>
</setting>
</KayeScholer.LitigationPortal.Documents.BLL.DocumentsBLLSettings>
</applicationSettings>
You should copy these sections into the "true" config file.
I'm addressing this exact issue in an application I'm in the midst of prototyping. Although Decker's suggestion of hacking the config files together should work I think this is a pretty inconvenient manual hack to perform as part of a build cycle. Instead of that I've decided that the cleanest solution is to just have each library parse its own library.dll.config file. Its still not perfect and it requires some extra boiler-plate code, but it seems to be the only way to get around the byzantine way that .Net handles these app.config files.
I have had this same problem for a long time - it's annoying.
I like the idea of making your own config file and having each DLL parse it, though it still might be easy to miss having to change the config.
One thing I have done in the past to at least make this a little easier is to make sure that any config values that the Setting1.Settings file are invalid.
For instance, I have a class that uses LINQ-To-SQL to talk to the DB. So it has a Setting1.settings file that it stores the connection string to database in. The default value that is entered (upon dragging and dropping the database tables into the designer) is the connection string of the dev database.
Once I have the DBML file created based off of the test database, I can go in and edit the Settings file and type in a database name like "FAKE_DATABASE".
That way, if you use the DLL in another project, and then forget to merge the config files to add in the proper config value for the DLL, at least you'll get an error saying something like "Cannot connect to FAKE_DATABASE".
Of course, if you have to work with the designer again, you'll have to change the value back to the value of your dev database.
Huge pain. They've gotta change this somehow.
Apparently your application is trying to read from the default config file (which is probably the application's config file). To make sure, add the key-value pair in the dll's config file to the application's config file, run the application and see if it is read this time.
I think I just found an explanation of why this isn't working for my DLL and my test application. Here is the concluding exception from some guy's blog:
The fix for this is to either make sure your application and the support assemblies have the same namespace or to make sure you merge the contents of AppName.exe.config and DllName.dll.config (yes when you compile a .dll now it generates this file, however it is ignored if you copy it to the application directory and is not automatically merged)
So either I have to keep the DLL and Application in the same namespace -or- I have to merge the contents of the DLL config file with the Application's config file.
(Doesn't this sort of defeat the purpose of the DLL? I thought a DLL was supposed to be an independent library.)
Perhaps this is why it works for my co-worker. The production application shares the same namespace as the DLL. (My test app clearly does not...)
UPDATE: I just sat down with my co-worker recently and talked about this problem again and it seems that it was never working for him either, but he hadn't realized it because he had set the initial value to be the same as the device we were trying to use. So of course it appeared to work at first, but as soon as we deployed it elsewhere with slightly different settings it was broken again.
I've seen a similar problem when using app.config. Try running your application from the .exe instead of from Visual Studio & see if it then behaves as expected.
It is possible that in your DLL you have the access modifier (for the Settings1.Settings) set to Internal (Friend for VB). Try changing the Access MOdifier to Public and see if that lets your application read/write values from dll's config.
The answer from Howard covers the theory.
One quick and dirty way of solving this is to parse the xml config file manually.
string configFile = Assembly.GetExecutingAssembly().Location + ".config";
XDocument.Load(configFile).Root.Element("appSettings")....
This code project article gives you some code which allows you to use a Class Library app.config file, and read it properly. And still use the Visual Studio GUI to manage the settings.
https://www.codeproject.com/Articles/246201/Settings-in-an-assembly-configuration-file
The mistake I think you all make is that you apparently make referece to the DLL Settings via Settings1.Default.IPAddress while you are simply suppossed to do this Settings1.IPAddress.
The difference is that when you use Settings1.Default.IPAddress the values are gotten from the hardcoded values imbeded in the assembly file (.dll or .exe) as Attribute [global::System.Configuration.DefaultSettingValueAttribute(...)].
While Settings1.IPAddress is the value that is editable in the file .dll.config (XML file)**. so any changes you make to the XML file, it is not reflected in hardcoded default value in the assembly.
Not this:
IP = IPAddress.Parse(Settings1.Default.IPAddress);
But try this:
*IP = IPAddress.Parse(Settings1.IPAddress);