Filenotfoundexception in Applicationsettingsbase

FileNotFoundException in ApplicationSettingsBase

Just an explanation for why this exception is thrown. You can repro the exception with this sample Windows Forms app. Start by adding a setting named "Setting" of type StringCollection. Click the dots in the Value column and enter a couple of strings. Make the form class code look like this:

public partial class Form1 : Form {
    public Form1() {
        InitializeComponent();
    }
    protected override void OnFormClosing(FormClosingEventArgs e) {
        Properties.Settings.Default.Setting[0] = DateTime.Now.ToString();
        Properties.Settings.Default.Save();
        base.OnFormClosing(e);
    }
}

Debug + Exceptions, tick the Thrown checkbox for CLR exceptions. Run the form and close it, the debugger will stop when the exception is thrown. The top of the call stack looks like this:

mscorlib.dll!System.Reflection.Assembly.nLoad(System.Reflection.AssemblyName fileName, string codeBase, System.Security.Policy.Evidence assemblySecurity, System.Reflection.Assembly locationHint, ref System.Threading.StackCrawlMark stackMark, bool throwOnFileNotFound, bool forIntrospection) + 0x2c bytes 
mscorlib.dll!System.Reflection.Assembly.InternalLoad(System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity, ref System.Threading.StackCrawlMark stackMark, bool forIntrospection) + 0x80 bytes   
mscorlib.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef) + 0x1d bytes   
System.Xml.dll!System.Xml.Serialization.TempAssembly.LoadGeneratedAssembly(System.Type type = {Name = "StringCollection" FullName = "System.Collections.Specialized.StringCollection"}, string defaultNamespace = null, out System.Xml.Serialization.XmlSerializerImplementation contract = null) + 0xcd bytes  
System.Xml.dll!System.Xml.Serialization.XmlSerializer.XmlSerializer(System.Type type = {Name = "StringCollection" FullName = "System.Collections.Specialized.StringCollection"}, string defaultNamespace = null) + 0x105 bytes  

You can see the XmlSerializer class hunting for an assembly that contains the XML serializer for the StringCollection class. The LoadGeneratedAssembly method looks like this with the boring bits removed:

internal static Assembly LoadGeneratedAssembly(Type type, string defaultNamespace, out XmlSerializerImplementation contract)
{
    ...
    AssemblyName parent = GetName(type.Assembly, true);
    partialName = Compiler.GetTempAssemblyName(parent, defaultNamespace);
    parent.Name = partialName;
    parent.CodeBase = null;
    parent.CultureInfo = CultureInfo.InvariantCulture;
    try
    {
        serializer = Assembly.Load(parent);      // <=== here
    }
    catch (Exception exception)
    {
      ...
    }
  ....
}

And Compiler.GetTempAssemblyName():

internal static string GetTempAssemblyName(AssemblyName parent, string ns)
{
    return (parent.Name + ".XmlSerializers" + (((ns == null) || (ns.Length == 0)) ? "" : ("." + ns.GetHashCode())));
}

This GetTempAssemblyName is the evil-doer in this case. The StringCollection class lives in the System.dll assembly, the method generates the name "System.XmlSerializers". This method is designed to find the assembly for your own classes, the one generated by Sgen.exe. Like WindowsApplication1.XmlSerializers.dll for your sample program. But StringCollection is a class in the .NET Framework, the assembly name it generates just isn't valid. There isn't actually a "System.XmlSerializers.dll" assembly in the framework.

Feedback reports about this behavior at connect.microsoft.com have all been closed with "By Design". It was, the original designers considered the cost of preventing the exception too high and decided to just catch the exception. Which all works fine, the exception is indeed caught. You just happen to see it because you got the Thrown checkbox turned on in the Debug + Exceptions dialog.

Making the Xml serialization code behave differently here is not an option. It would have been easy enough for them to simply filter out types in the System.dll assembly, but that's a potentially never-ending battle, there are a lot more assemblies in the framework. A workaround is to use your own class to store the setting instead of using a StringCollection.

XmlSerializer giving FileNotFoundException at constructor

Believe it or not, this is normal behaviour. An exception is thrown but handled by the XmlSerializer, so if you just ignore it everything should continue on fine.

I have found this very annoying, and there have been many complaints about this if you search around a bit, but from what I've read Microsoft don't plan on doing anything about it.

You can avoid getting Exception popups all the time while debugging if you switch off first chance exceptions for that specific exception. In Visual Studio, go to Debug -> Exceptions (or press Ctrl + Alt + E), Common Language Runtime Exceptions -> System.IO -> System.IO.FileNotFoundException.

You can find information about another way around it in the blog post C# XmlSerializer FileNotFound exception (which discusses Chris Sells' tool XmlSerializerPreCompiler).

Slow ApplicationSettingsBase

I dont see annything strange in having a thread safe settings mechanismm? If it is slowing your hihgly concurrent theads down, you should try to use local variables istead of querying the getsetting fast again. I think a redesign of your settings request mechanism would help performmance considerably.

XAML designer: 'FileNotFoundException'

You can simply remove this error by setting CopyLocal=true for the mentioned dll.

This way it will not conflict between the existing installed one and the newly added one from the Nuget Package.

WPF Properties.Settings throws exception on launch and close

That exception is not so unusual in my experience. What is unusual is that the exception is (apparently) unhandled in your situation. Usually, (again in my experience) that exception is silently caught and handled by some other mechanism.

You are not, by any chance, running this in the VS debugger with 'break when an exception is thrown' are you? That setting is under Debug -> Exceptions..., by the way.

SwiPICs.dll PlEngine.Initialize FileNotFoundException

The error is not very clear, but is caused by the fact that the program needs to know where to find the DLLs that run SWI-Prolog are located. There are a few ways to do this but the simplest is to add the directory (e.g. C:\Program Files\swipl\bin) containing the SWI-Prolog executable (swipl-win.exe) to the Windows system PATH variable.

After changing the system PATH variable you will need to restart Visual Studio if necessary.

Could not load MyAssembly.XmlSerializers.dll. The system cannot find the file specified

The situation was a little trickier than I had expected. The XMLSerializers DLL for that assembly seems to be essential for authentication in my solution, and just "Press[ing] F5 to continue running until the real problem occurs" did not lead to some unrelated error.

I have not been able to completely understand what the underlying issue is, but it seems that there is a problem creating the DLL dynamically after Visual Studio is upgraded.

The way I have worked around the issue is by running the sgen tool to manually create the serializers and setting the flag "Generate Serialization Assemblies" to Off. The process can be automated by adding a post-build instruction to run the tool.

That being said, I have no idea why this issue comes up in the first place, as I am certain that I did not open the project in VS2012.

---

Related Topics