1

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?
Improve this question
7
  • I don't think I'd ever include System in one of my namespaces - if it confuses me, it's like to confuse the compiler. But, you can usually fix weird namespace issues by using the alias feature of the using keyword. Something like using Management = Foo.System.Management;. It may take some experimentation to get it right (and comfortable in your use case) Commented Dec 12, 2022 at 16:15
  • @Flydog57 right, the alias will work for me, but like I said... some code generation imports cause the conflicts. The reason I named my library System was because I abstracted some general System functions that we use Commented Dec 12, 2022 at 16:18
  • 1
    Can you influence/configure the code generation in a way that it places the using System; directive outside any namespace declaration? Because then the using directive would sit in global namespace scope, with the closest "System" namespace the global::System namespace. Or can you configure the code generation to always generate using directives with the absolute namespace name rooted in global, i.e., using global::System; instead of just using System;? Commented Dec 12, 2022 at 16:24
  • @MySkullCaveIsADarkPlace not really familiar with how to influence the code generation. It is a WPF application and it is the File.g.cs files that are throwing the errors Commented Dec 12, 2022 at 16:26
  • 1
    Wait, doesn't the code generator for .g.cs files not place the using directives outside of the namespace declarations anymore? (I only have old .NET Framework WPF projects here i can look at, and for those the generated .g.cs files have the using directives outside any namespace declarations.) Are you sure you are having a problem with using directives and not just with some fully qualified type names like System.SomeTypeName or System.Blah.SomeOtherTypeName within the generated code? Commented Dec 12, 2022 at 16:28

1 Answer 1

Reset to default
2

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.