"URI formats are not supported." exception just started showing up in really old, unchanged code

Question

Ok, I'm experiencing a truly random bug and I cannot find any reason why this would happen. I have an application that I update that was first developed MANY years ago. I work on a sizable dev team whose sole responsibility is to manage this application and we've come to accept that the project is a bit of a "franken-code" project. We are but humble developers in a line of many generations of developers who've inherited this project. (This will be important to know later.)

There is a portion of our application that deep within the initialization process calls the following code:

string strPath = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().CodeBase);
string strFile = strPath.Substring(6) + "\\" + FILE_NAME;

Here's the deal. My fellow team members, and myself, have been able to modify and build higher-level, UI and DB related sections of our solution for an eternity. I, nor anyone else, has modified the above code, or any code in the same code file (or project within the solution, for that matter.)

However, today while working in a completely different section of my application I began to get some really odd "Out of Memory" exception errors. I'm not sure if that relates to my problem but I felt it was worth mentioning that after rebooting my machine and reloading the VS solution, I'm now consistently getting the following exception when I attempt to run a debugger test, when the initialization process attempts to execute the above mentioned snippet of code:

Exception: A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll Message: URI formats are not supported.

I've googled this error message and it looks like the original dev was simply doing this wrong. This seems to be a common error, but what baffles me is that this has never been a problem until, randomly, today.

I know this is an odd question, but is there a way to fix this without modifying this code. As I mentioned, this is a really complex application that often feels a bit cobbled together. Our team is attempting to clean up, or replace, much of the applications functionality but there are portions we simply do not touch because we have no solid clue how the application will work once it is deployed to our production environment. This is a highly-critical application and it cannot be broken.

Might anyone have any clue what may cause this to "magically" start happening? Especially since I have been working in UI-related code, and no where near the low-level, configuration resolution section of code where this came from.

ADDITIONAL NOTES

• We use source control. If I download, build an run an older revision of the application, it works.
• We use AnkhSVN and when I inspect my changed files, again, there is nothing that has been changed that relates to the code that is now failing.
• No one else in my team has ever seen this.
• To my knowledge, I've not tweaked any setting associated with my project. I've taken a look at my project properties and everything looks normal. I guess there is a chance that I've hit some odd key-combo and enabled/disabled something through shortcut-keys, but I have no clue what that might be.

Any help is appreciated. Sorry for the novel. I'm just stumped and I'd rather not use a different method for acquiring this path string if there is ANY chance that altering this process could behave differently in different user environments.

Answer 1

I can only assume some working file within the Visual Studio that is associated with the project/solution had become corrupt. I searched through the text of my project files, and all of my code, and I didn't see anything out of place.

As I mentioned, we use source control. To attempt a fix, I pulled down the same source revision that I initially pulled for my current task. I compiled and ran the application. Everything worked properly in its "vanilla" state.

Next, I copied in all of the files I knew I had modified. I hadn't added any new project references or resources, so I just copied over the modified .cs files. I built and ran the application and I've had no trouble since the pull from my branch.

This does not answer the question of why this occurred, but this method can provide a solution to the problem.

Answer 2

I can confirm this change in Path.GetDirectoryName occured to me after installing VS 2015 and rebuilding our project in it so it seams to be .NET 4.6 feature. Rebuilding the project again in VS 2013 returns the previous behaviour where Assembly.CodeBase with "file:" prefix is acceptable by Path.GetDirectoryName without any exception. But rereading the MSDN documentation, there is a statement that "file:" paths are not supported, but this is not mentioned in ArgumentException thrown in VS 2015 code.

Answer 3

First of all, find out how many versions ago this started occuring: start with the current version, and work back changeset by changeset until it no longer fails.

It sounds like, for whatever reason, System.Reflection.Assembly.GetExecutingAssembly().CodeBase now returns a string that GetDirectoryName doesn't like. So, check the project files, the .sln, the repo config, anything that could cause a file to be in a different location.

If you can't find anything there, check the other files from that same commit, even if they appear that they shouldn't be related.

First Chance Exceptions generally happen when you've got multiple threads happening, so check for new threads that weren't in the previous version. I've also had situations where First Chance exceptions would only get caught under certain situations, and are silently ignored otherwise, so look changes in Debug settings: it's possible that this problem has always existed, you just haven't had the right settings to catch it until now.

Remember that under a source control, other people can change things that are "yours", even if only by accident.