Visual Studio namespace gotcha
-
TL:DR - C# + Visual Studio 2017 + careless developer = wasted time. I decide to move image processing to its own DLL, so I create a new DLL and use the namespace ImageProcessing. All well and good, that compiles. I then try to use it from my main application: Error - The type or namespace 'ImageProcessingBase' does not exist in Station.ImageProcessing. Fool me, I did not read the Station portion of Station.ImageProcessing, so it took me far too long to figure out I needed to get rid of the Station.ImageProcessing namespace before I could access the new ImageProcessing namespace from the Station namespace, unless I want to add a lot of alias commands. Now Station.ImageProcessing is no more and everything compiles. Why didn't Microsoft have a different convention for partial namespace definitions? Something like .ImageProcessing for accessing Station.ImageProcessing from the Station namespace would work.
-
TL:DR - C# + Visual Studio 2017 + careless developer = wasted time. I decide to move image processing to its own DLL, so I create a new DLL and use the namespace ImageProcessing. All well and good, that compiles. I then try to use it from my main application: Error - The type or namespace 'ImageProcessingBase' does not exist in Station.ImageProcessing. Fool me, I did not read the Station portion of Station.ImageProcessing, so it took me far too long to figure out I needed to get rid of the Station.ImageProcessing namespace before I could access the new ImageProcessing namespace from the Station namespace, unless I want to add a lot of alias commands. Now Station.ImageProcessing is no more and everything compiles. Why didn't Microsoft have a different convention for partial namespace definitions? Something like .ImageProcessing for accessing Station.ImageProcessing from the Station namespace would work.
Because that would be an ambiguity in one of the few places where ambiguity would break the system. By and large, C# is really good about supporting abstractions. One of the main reasons for this is that the whole thing is underpinned with stringent structural rules in terms of where and how code is loaded. These rules, which include namespace definitions, make the entire idea of dynamic module loading work without a bunch of odd checks and locks. An ambiguous namespace definition would break this system. Do I want System.Timers or System.Threading.Timers? The APIs are different, so if I load one ambiguously, I'd need to do some type checks before using anything from it an likely set aside some buffers and concurrency control while making the determination and loading the code. Or I can just type: using System.Threading.Timers; Side note: ReSharper automatically detects namespace issues and can automatically correct them for you.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor