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.
Related
Is there a way to set the namespaces references for all files within a folder?
Example: All my classes in a certain folder needs to reference System.ComponentModel (and many others) and I don't want to set the references every time I create a new class.
No, this is not possible. Each file represents a separate compilation unit and the C# language specification states:
A C# program consists of one or more compilation units, each contained in a separate source file.
…
The using_directives of a compilation unit … have no effect on other compilation units.
As others suggested, development tools that integrate with Visual Studio are typically used to perform such routine tasks as generating and maintaining the set of usings in each file.
I have been given a folder than contains many solutions in subfolders along with their code. Each solution builds a PrinterDriver.dll. What I am trying to do is create a master solution that I can add all the projects into and then they will all compile every time.
I cannot at the moment do this, when I add each to the master I get an alert telling me that a project of that name already exists. what is the best way to do this?
I'd urge you not to create a master solution containing projects with the same name, that will end up a mess... You'll have to change assembly names and namespaces and as you've found you end up with dozens of namespace ambiguity errors.
all the projects ... will all compile every time
If the aim is just to compile all the projects at once, every time, then simply write a MSBUILD script that uses all the project files to compile outputs.
Eg: Compiling a .vbproj or .csproj project file without Visual Studio
If you do want a master solution it will require surgery. One way would be to create interfaces (or abstract classes) that reflect the method signatures of each class in every project and using IoC load different implementation classes depending on the target.
Warning: Be wary about changing namespaces, while prefixing namespaces with a unique name may sound simple. You have to be aware of the impact especially on code library's (like Printer.DLL) that other projects reference.
I have a .Net class library that contains many different namespaces and multiple sub-dependencies (referenced assemblies).
Sometimes a project references only one specific namespace, sometimes just one single interface, of such class library but still upon compilation all sub-dependencies (dlls) are copied into my project assembly folder (\bin folder).
So if class library MainClassLibrary references subLib1, sublib2, and sublib3 and when I create a new project that references MainClassLibrary then subLib1.dll, subLib2.dll, and subLib3.dll are also all copied into the binary folder of my project even if I only use an interface definition in a segregated namespace within MainLibrary that does not depend on any of the sub dependencies.
Is the only way to split up the class library into smaller pieces or is there a better, easier way?
even if I only use an interface definition in a segregated namespace within MainLibrary
That is the reason that sometimes only one or a handful of interfaces are put into a separate assembly (Project).
But in general, focus on minimizing the logical dependencies and don't worry to much about how many DLL files are copied.
And as #Alexei mentioned in his comment, this (automated) proliferation of DLL files is the solution to DLL Hell.
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.
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.