I have a library - Foo.System.Management

I have an application - Foo.New.Application

In this application, Using System; is imported, and what ends up happening is this is being resolved to Foo.System and causes my project to throw error's saying

The type or namespace Diagnostics does not exist in the namespace Foo.System

My assumption is that because of the same Base namespace Foo it is causing that resolution. Looking through the Namespace Docs I can't really find a clear explanation of this.

• What are my options in my Foo.New.Application?
• Some of those Using System; directives are code generated so I cannot control aliasing. Should I just rename the library?
• Is it bad practice to create a namespace like Foo.System for that reason?

CodePudding user response：

Citing the design guidelines:

❌ DO NOT introduce generic type names such as Element, Node, Log, and Message.

There is a very high probability that doing so will lead to type name conflicts in common scenarios. You should qualify the generic type names (FormElement, XmlNode, EventLog, SoapMessage).

Core namespaces include all System namespaces, excluding namespaces of the application models and the Infrastructure namespaces. Core namespaces include, among others, System, System.IO, System.Xml, and System.Net.

❌ DO NOT give types names that would conflict with any type in the Core namespaces.

For example, never use Stream as a type name. It would conflict with System.IO.Stream, a very commonly used type.

https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces

So, yes, you should find a more suitable name for your library that follows the design guidelines for names of namespaces and it is indeed bad practice to use System as part of your namespace name.