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.
Related
I'd like to create a namespace in c# that can be found in any project. Not just the one that it is located in. like the system namespace. Is that possible and if yes I'd like to know how.
I already googled and didn't find anything
Classes in the System namespace are part of the Base Class Library (BCL) that gets included as part of the .NET Runtime. The only way for you to have your class be as globally accessible as, say, the System.String class, would be to convince Microsoft to add your class into their BCL. That is rare, but not unheard of. The IObservable<> interface is an example of a type that was added that way.
However, there are tons of classes that people are using every day without having them added to the BCL. If you're willing to accept one additional step for people to take with their projects, in order to leverage your project, you can publish your project's output as a Nuget package. Then people only need to add your Nuget package (referenced by its package name), and they'll have access to the public API defined by the types in your DLLs.
Consumers of your package will still need to reference the namespaces of the types they want to use, either explicitly or via a using directive. In C#, a "global using directive" only makes the namespace globally available within the project that the directive is found in.
If you only want your types to be accessible from other projects found in the same solution, Nuget isn't necessary: you can add a project reference.
There are a lot of nuances I'm glossing over (i.e. differences between namespaces and DLLs and packages), but which it would be helpful for you to read about.
One of solution:
You need to create library(DLL) and refernce it in projects.
If you using visual studio 201x you can create project with type class library.
The library namespaces can be found use like this ´using MyNamespace;´
example of class in library:
adding refernce to project:
example of using your own class library:
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.
Can you use namespaces in one program to get the classes from those other programs in your program? Or do you do this using assemblies? And how do you do it?
To use classes defined in another program (let us call this program an "assembly"), you can reference that assembly in your program/application and use the classes. The classes have to be defined as public in that other assembly.
An assembly is basically an .exe or a .dll, as explained in this answer.
Usually classes that are meant to be reused are defined in a class library and compiled to a .dll.
The goal of namespaces is to separate the code into meaningful pieces, as explained here.
A namespace creates a sort of "full name" for a class. So, in you program you will have to reference a class defined in another program/assembly by its full name, meaning using its namespace and its class name.
If you are trying to use code from one c# project in other you just need to add a reference in the project you are going to consume the code to the project with the code to be consumed.
If you are trying to consume code from an already compiled assembly and this compiled assembly is .net you can either use reflection or .net decompiler to get the code.
Jetbrains have a .net decompiler.
Basically, I developped a small library with some common fonctionnalities that I use in all my projects. For some political reasons, I cannot choose a generic name for that library (including namespace and assembly name). Usually, it must include the name of the enterprise, something like this for the namespace: Enterprise.ProjectName.XXX.YYY.
For the moment, I'm doing a copy of my library, then I'm renaming the namespaces manually with Visual Studio, and finally I'm recompiling the whole thing.
So my question is the following: Is it possible to create a small program that takes an assembly as input, rename all namespaces from MyLibrary.XXX.YYY to Enterprise.ProjectName.XXX.YYY as well as the assembly name?
What are the steps to follow?
[Edit]
Generating the assembly automatically seems to much work. I will use resharper and/or CTRL+ALT+F like I did so far. Thanks for the answers...
You could use Mono's Cecil project to disassemble the assembly, inspect each type, rename or recreate the type with a new namespace, and generate the resulting assembly.
That being said, it might be simpler to use a tool like Resharper which allows you to rename namespaces correctly within the code base.
Some options:
If you are copying the entire source code for your library into your new project, you can use a refactoring tool like Resharper to "Adjust Namespaces". This is a pretty quick and safe refactoring.
If you just need to avoid shipping the internally named assembly, you may be able to use ILMerge to 'hide' the internal assembly during a post-build step. This is viable if it's just a perception issue for the final assembly names in the binary output directory.
Deal with the issue at the political level by describing your internal library as being no different from any other third-party dependency. Then the naming is no longer a problem. This may solve other problems if you're shipping the source code of this library to multiple clients, as it clarifies that you are not giving full ownership of your 'shared' code to each client. Otherwise they could potentially argue that you are not allowed to use that 'shared' code in projects for other clients, since it is clearly owned by them, having their enterprise name in the namespace.
Say I have foo.cs and bar.cs. if I create two seperate projects for each source file and compile them to two DLLs, I have no problem in importing and using them in other projects.
What should I do if I want an output of single DLL?(with keeping separate source files) Can a DLL file have two namespaces? if not, How can I place contents of foo and bar into single namespace? (I can edit them)
if I create two seperate projects
Create one project with both files in it to produce one DLL as output. The namespaces can be anything you'd like, though convention suggests that classes within a project share a common root namespace.
You only have to add both files to the same Project.
Can a DLL file have two namespaces?
Yes. And conversely one namespace can be used in multiple DLLs.
See ILMerge.
Microsoft says:
ILMerge is a utility that can be used to merge multiple .NET assemblies into a single assembly. It is freely available for use from the Tools & Utilities page at the Microsoft .NET Framework Developer Center.
The namespaces are completely independent from the source files and projects. You can have several namespaces in one project or even in one file as well as one namespace for several projects. And of cause you can have several source files in one project (you almost always have many source files per project unless it's a "Hello World"-project)
You can change the default namespace given to new source files in the project properties in the "Application" tab, field "Default namespace". You can also create new folders and subfolders in your project. The name of these folders is automatically added to the default namespace of new source files created within these folders (separated by dots .). And of cause you can always edit the namespace-statements manually. You add or remove and nest namespace statements.
You can also have several projects in one solution. You can even mix projects of different types and languages (e.g. VB and C#) within one solution. Every project usually generates one assembly (dll or exe). It makes no difference whether the projects are within the same solution or not from the technical perspective. It's only a matter of organization.
See:
MSDN: Names of Namespaces
MSDN: Namespace Naming Guidelines
SO Question: namespace naming conventions.
Example of a complex solution:
C# namespaces are quite open.
Yes, you can have several namespaces in one library.
But also: you can add things into an existing namepace. For example: you could add extention methods into the System.Linq namespace, so that you only have to include the dll without requiring additional includes.
You can have multiple child namespaces within a single project. It might be better practice to at least give the project (and, once compiled, the DLL) an overarching namespace, though.
If you only need to merge a single class in these files you can use partial classes
But they have to be in the same namespace anyway.