3

So I originally encountered the issue described in this question: XmlSerializer giving FileNotFoundException at constructor

However, we just upgraded from Visual Studio (VS) 2013 Pro to VS 2019 Pro. Now, when I have all Common Language Runtime (CLR) Exceptions turned on (break when thrown) including System.IO.FileNotFoundException, I do not get a break on the exception. I thought it was something to do with the targeted .NET Framework (we also upgraded to .NET 4.8).

That said, I did a test:

  1. Created a test WinForms project in VS 2019 targeting .NET 4.5.2, our starting framework version.
  2. Add the following the default Form1 class:
public static readonly XmlSerializer kXMLSerializerList = new XmlSerializer(typeof(List<string>));
  1. Ensure all CLR Exceptions including System.IO.FileNotFoundException were on.
  2. Build.
  3. Launch the debugger in VS 2019.

Result: No break on an exception

OK, let's try VS 2013

  1. Start VS 2013
  2. Open the same project.
  3. Rebuild.
  4. Launch the debugger in VS 2013.

Result: XmlSerializer FileNotFoundException

So it doesn't seem to be a .NET Framework version dependency. An IDE dependency? That confuses me. Or is it a C# version dependency? Anyone have any clues?

pigeon
  • 151
  • 9
  • 1
    In each version of VS, go into the project's build settings, click on advanced, and see what version of the language each is using. They are probably using a different version of the language. I think by default they're set to "Use Latest", but *latest* might be different for VS2013 vs VS2019. –  Jan 14 '20 at 14:50
  • Just to be sure: is this issue about vs _not breaking_ at the exception or the exception _not being thrown_? – René Vogt Jan 14 '20 at 14:59
  • @Amy: In VS 2013, Language version in VS 2013 is "default" and in VS 2019 is "Automatically selected based on framework version" with the control disabled. According to the[link](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version) under the control, VS 2019's compiler is C# 7.3 for all .NET Framework version. – pigeon Jan 14 '20 at 15:00
  • @RenéVogt, not being thrown based on the assumption: it is not breaking because it is not being thrown. I believe I have exception breaking set up correctly. – pigeon Jan 14 '20 at 15:03
  • So it seems to be a C# 5.0 (if I change default to C# 5.0 in VS 2013, I still get the exception) vs C# 7.3 difference. – pigeon Jan 14 '20 at 15:07
  • hopefully they removed this in the newer version. be glad that it is no longer thrown unnecessarily, why do you care? – Cee McSharpface Jan 14 '20 at 15:08
  • 1
    @CeeMcSharpface. Don't get me wrong, I am very glad! It was annoying toggling CLR Exceptions on and off to avoid stepping through all of them. I may have a little OCD :). Just trying to learn more the compiler, IDE, and framework. – pigeon Jan 14 '20 at 15:09
  • 1
    start looking here: https://referencesource.microsoft.com/#System.Xml/System/Xml/Serialization/Compilation.cs,228 – Cee McSharpface Jan 14 '20 at 15:12
  • 1
    Maybe you have different settings for "Just My Code" in VS 2013 and 2019 or the framework source code is available for the older version, but not the newer one. – NineBerry Jan 14 '20 at 16:14
  • @NineBerry, you were right. Updated answer...this is embarrassing. – pigeon Jan 14 '20 at 16:45

1 Answers1

1

Bah. It was that "Just My Code" was checked.

I was thinking I had that unchecked, but I was wrong...sorry to all...

Hangs head in shame :(

pigeon
  • 151
  • 9
  • In my personal experience, 99% of the time an issue with code stems from the language version and/or the framework version, usually the former. It's almost never VS itself. While the code you found might not be different between versions, the parameters passed in might be. I have no idea how one would check that though. –  Jan 14 '20 at 16:07