I'm using VS 2019, a C# ASP.NET core 3.1 WEB API.
For reasons (I'll explain if anyone needs them), VS asked me to turn "Just My Code" off. A few hours later, in a different project, I got an System.IO.FileNotFound exception. The problem was a DLL didn't exist. The problem is, that DLL literally doesn't exist, it's not supposed to exist, and it will never exist.
After turning off Just My Code, I was working on a different project, Project-A (WEB API). It has a project reference to Project-B (Class Library). Project-B uses a NuGet package (Package-C). I wrote all 3 of these things.
I trigger an endpoint call to Project-A, the controller calls to Project-B, and when B tries to call a method in Package-C, I get a System.IO.FileNotFound exception. It's looking for Package-C.XmlSerializers.dll. But that's not a real thing. As I said, I wrote Package-C, and that DLL just ... isn't a real thing.
If I turn on "Just My Code" the problem goes away. We have not deployed this code yet, and I'm worried that it won't work on the server. And if it doesn't I don't know how I'm going to provide an imaginary DLL.
- Why is .NET looking for a DLL that doesn't exist and isn't supposed to exist?
- Why is Just My Code triggering this behavior? (I'm not 100% sure what Just My Code does, just a few bits I gleaned before writing this post.)
Some things that may or may not matter:
I'm running Project-A et al in Debug mode, locally, using IIS Express, and CORS (requests coming from an Angular app being served from VS Code).
I recently updated Projects A & B to .net core 3.1, because a co-worker recently updated Package-C to 3.1 (and added some functionality), and I needed the new functionality.
Package-C does do XML Deserializing using
System.Xml.Serialization; it reads XML from an old SOAP endpoint and deserializes it into a model.I have the out-of-date source code for Package-C on my hard drive (I haven't pulled co-worker's changes yet).
Thank you!
