I'm trying to understand C# namespaces. Suppose two namespaces exist with the same name and they have identical contents, i.e. all classes and methods also have identical names. How can the compiler distinguish between the two if I try to call a method, e.g. MyMethod in class MyClass in namespace MyNamespace? It's not likely a real-world scenario, but I find the information useful for understanding purposes.
Second question: When I dot on a namespace, e.g. System, I get a set of related namespaces like System.Configuration etc., but when I go to Microsoft's documentation I cannot find any namespace named Configuration contained in System namespace. Why is that? I can of course find the namespace if I look for System.Configuration, but I don't understand why the System.Configuration namespace is not nested inside the System namespace.
If you have two types that have the same name and same number of type parameters, and exist in the same namespace, then the assemblies that they are in must be different.
If your project references the assembly that one type is in, but not the other, then you will obviously only be able to refer to the type that is from the assembly that you referenced. If your project references both assemblies, then there will be a compiler error, like this. To fix it, you can use an extern alias.
Not being able to find System.Configuration in this page is merely due to how Microsoft organises their documentation. They have decided to list all the namespaces out here, rather than display a hierarchy. Note that System.Configuration is part of the .NET Platform Extensions, not plain old .NET, so you have to choose that in the dropdown.
Related
The situation I am encountering is the same as here:
WPF Custom Namespaces not working
XmlnsDefinition only works for namespaces in other assemblies, not in
the same assembly.
However, I don't really get what is exactly meant by "same assembly" and "different assembly". If AssemblyInfo.cs and the XAML files are in the same assembly, how can I move AssemblyInfo.cs away from the assembly to another?
Documentation does not refer to such any limitation.
Mapping CLR Namespaces to XML Namespaces in an Assembly
WPF defines a CLR attribute that is consumed by XAML processors in order to map multiple CLR namespaces to a single XAML namespace. This attribute, XmlnsDefinitionAttribute, is placed at the assembly level in the source code that produces the assembly. The WPF assembly source code uses this attribute to map the various common namespaces, such as System.Windows and System.Windows.Controls, to the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace.
The XmlnsDefinitionAttribute takes two parameters: the XML/XAML namespace name, and the CLR namespace name. More than one XmlnsDefinitionAttribute can exist to map multiple CLR namespaces to the same XML namespace. Once mapped, members of those namespaces can also be referenced without full qualification if desired by providing the appropriate using statement in the partial-class code-behind page. For more details, see XmlnsDefinitionAttribute.
https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/xaml-namespaces-and-namespace-mapping-for-wpf-xaml#mapping-clr-namespaces-to-xml-namespaces-in-an-assembly
I'm pruning out unnecessary using directives, and am not sure if I should leave
using System;
in all my files or not?
In a Xamarin.Android Visual Studio class file, this directive
imports the namespace defined in
...\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\System.dll
However, I have many files that are not explicitly using any types from there (which can be indicated by the faded/grayed syntax highlighting). However, it is my understanding that .NET primitives are aliases that the compiler substitutes for types within the System namespace (int <=> System.Int32), so I'm not sure if this could potentially cause any issues. The compiler never throws any kind of ambiguity error if omitted (between .NET System and Xamarin System), and my testing so far hasn't resulted in any issues.
You ask that question because you have a misunderstanding between the using directive and referenced assemblies.
using does not reference any assembly.
The References added to your project do (s. the "References" node in the Solution Explorer, or "Dependencies" in .NET Core projects), hence their name, References.
using only allows you to shortcut using namespaces or types available in the previously separately referenced assemblies in your code, e.g. writing Console.WriteLine() instead of System.Console.WriteLine().
You may ask why this differentation has been made in the first case. Well, one issue would be that if you had two assemblies defining types with the same name (let's say, some XBox related assembly also providing a Console type) and you would also reference the assemblies with the using directive as you were thinking, there'd be no way to differ between System.Console or XBox.Console in code, as there are now two Console types accessible at the "same time".
To come back to reality, you can remove any using directives which are grayed out with absolutely no impact on how your application behaves as the references to the assemblies will still stay intact (nothing in the "References" node in your Solution Explorer will have changed), and so your application will still be able to access the types defined in System - just you won't be able to use them like Int32 instead of System.Int32 for example.
Now the joke about the primitive types is that C# provides keywords to shortcut those types like Int32 at any time (no matter if you have using System; on top of your file or not) by writing simply int, or bool for System.Boolean, and so on. That's the reason why your directive is grayed out, because you used those primitive types (if at all) through their keyword. Replace one int with the actual type name Int32 and you'll see the directive not being grayed out anymore.
If it's greyed out then yup, delete it. You don't need it for primitive types, only for objects inside that namespace such as DateTime or Guid.
Using directives have nothing to do with what assemblies are in use, only to help the compiler resolve types that are not qualified with namespaces. Any greyed out using can be deleted.
Is it a general guideline to have at least one namespace per assembly?
In what case, should multiple assemblies generally share the same namespace?
Development Environment : C# and .NET
From MSDN
Assembly
An assembly is a collection of types and resources that forms a logical unit of functionality. All types in the .NET Framework must exist in assemblies; Each time you create a Microsoft Windows® Application, Windows Service, Class Library, or other application with Visual Basic .NET, you're building a single assembly. Each assembly is stored as an .exe or .dll file.
Namespace
Namespaces are not a replacement for assemblies, but a second organizational method that complements assemblies. Namespaces are a way of grouping type names and reducing the chance of name collisions. A namespace can contain both other namespaces and types. The full name of a type includes the combination of namespaces that contain that type.
The answer is -- it depends.
If your assemblies are all small components of a given project, they may not need their own namespaces if they are distinct, self-contained and all "fit" under the namespace for the overall project.
If you're building assemblies which are only tangentially related and could easily be used in a wide variety of projects, you may want to group these in their own namespace.
If you're creating a class which has similar functionality or duplicate members to an existing class in your project or the CLR, you'll want a namespace for that too.
I would suggest to let the namespace match it's file location. Try and install resharper, you will see what i mean.
I do not know of a case where assemblies should share the same namespace. Only the first part of a namespace should be the same, the name of the company or product.
See this post from Mark
And this post to tell Resharper to get around this.
I'm using a MS namespace but Visual Studio is telling me I don't have a reference to it. Is there a place you can go to and lookup namespaces?
Thanks
If you mean "to find which dll I need (per-type)": MSDN?
For example, CLSID
Namespace: Microsoft.Aspnet.Snapin
Assembly: AspNetMMCExt (in AspNetMMCExt.dll)
You can normally find the MSDN page about a specific namespace by going to http://msdn.microsoft.com/namespace. So, for example, to find out about System.Web you could go to...
http://msdn.microsoft.com/system.web
That in itself doesn't help you. You'll need to click through from there to the specific types you're using, and it'll tell you (near the top) the name of the DLL that implements the type.
Remember that a namespace can contain types that are defined in more than one DLL.
See http://msdn.microsoft.com/en-us/library/wkze6zky(VS.80).aspx for how to add a reference
You will also need the assembly.
For Microsoft and System namespaces the easiest way is http://msdn.microsoft.com/library or, if MSDN installed locally, its index.
If you want to know which assembly a certain class is located in you can simply check the documentation (it's noted on the class overview page of the class). Note that one namespace might very well be spread out over more than one assembly.
You need to first add reference to the DLL before using it in your code with the 'using' keyword.
Right click the project > add reference > in the .Net tab select the component and click ok. Then build your code.
You can't find the DLL for a specified namespace in all cases because multiple types belonging to the same assembly may reside in different assemblies.
The fastest way to get there would be to google to the MSDN page for the specific type (class) you are using. Let's say XDocument.. I put `msdn xdocument class' into google. First result is the page I need. Click!
Under the class name you'd see a section like this
Namespace: System.Xml.Linq
Assembly: System.Xml.Linq (in System.Xml.Linq.dll)
This shows you the namespace that the type belongs to (for which you may need to add a using in your code)
and the DLL you need to 'Add Reference' to.
I am defining some Expression variables in my app and need to have a reference to Microsoft.Scripting.Core. That assembly includes the same namespace as the System.Core assembly from the main .Net framework.
I want to use the defintions from the System.Core assembly as it's stable whereas the Microsoft.Scripting.Core is alpha.
How do I tell my app to preference the System.Linq.Expressions namespace in System.Core instead of Microsoft.Scripting.Core but still be able to keep the reference to it?
As Marc says, it's not terribly nice - but extern aliases are the way to go.
In the "References" part of solution explorer, select the System.Core assembly, go to properties. Change the "Aliases" property to include "syscore", e.g.
Aliases: global,syscore
Then at the top of any file where you want to use System.Linq.Expressions, type:
extern alias syscore;
using syscore::System.Linq.Expressions;
It's ugly, but at least it's possible :)
As a caveat, I've seen some problems when it comes to extension methods and extern aliases, as described in this question.
If they are the same namespace but different assemblies, then you may need to look at "extern alias", but that gets very messy very quickly.
If they are different namespaces, then simply use different using directives; you can also use using aliasing. However, lambdas will always (AFAIK) use the original namespace.