We Keep Coding

Referenced DLLs with shared classes

Here's the issue I'm running into.
Project #1 - DLL
- Includes SomeCommonFile.cs file with several classes
Project #2 - Different DLL
- Includes SomeCommonFile.cs file with several classes
Project #3 - A web service
- Includes SomeCommonFile.cs file with several classes
- Includes references to both the DLL files.
So I've got the DLLs imported in just fine in Project #3, after putting aliases on the references, and "extern alias" at the top of the relevant code files.
But here's the problem when coding in Project #3: every single class in that SomeCommonFile.cs has three versions - one for each dll, and one in Project #3. Is there any easy way to structure this so that I don't have to have conversion functions all over the place (converting Project1DLL.CommonClasses.MyClass to WebService.CommonClasses.MyClass, etc)? At this point, I'm at the point where I'm going to Link Projects #1 and #2's code files instead of their DLL, just to simplify the classes, even though that sounds bad from a maintenance perspective.

The solution is to not include the common classes in each of three different projects in your solution.
If both of your DLLs need to reference some common code, and neither can reference the other, then have a 4th DLL with the common code that they both (along with the web project) reference.
Now you only have one copy of the classes, and they all play nice with each other.

Create a single "dll" starting from two independent projects (same solution)

I have a small solution with 2 projects "Class Library" independent, ie, no project is used as a reference in another.
The first project is called "Extension1" and the second "extension2". I would not want to use this solution in another project and having to reference the two dlls separately, I need to create a single dll "CustomExtension.dll" and that it has the two ("Extension1.dll" and "Extension2.dll") to reference only dll "CustomExtension.dll" on a new project using only the respective namespace. Is this possible?
PS: Windows 8 - Visual Studio 2010 Professional - C#

Might want to take a look at ILMerge. We use it in a lot of our projects for combining multiple dll's into one.
http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
http://www.microsoft.com/en-us/download/details.aspx?id=17630

It seems like this could be a very tedious task. Take a look at this answer to a previous question:
https://stackoverflow.com/a/6573711/329928
You have to do that by compiling the code using csc.exe outside visual
studio and passing the command-line parameters yourself (all .cs
files).
This will be a bit tedious but can be done. Look here: http://msdn.microsoft.com/en-us/library/78f4aasd.aspx

Is it possible to import class file without converting it to a dll in c#?

There are a lot of variables and methods in my program and I want to seperate some of them in other class files. But as the program grows the methods and functions can change.
I searched on the net but many people generally speaking for dll files. Without making a dll file, how can I arrange my code and split into small class files?

Yes, just split it out in to a separate file in a new class but still inside the same project. The term for what you are doing is called Code Refactoring. There are some tools built in to Visual Studio to make it easier to do, and there are some 3rd party tools that add even more features to make it easier to do.
But all it boils down to is just making new classes in the same project and referencing those new classes from where you took the code out from.

You can add folders to your solution. Classes are by default a namespaceprovider, so that classes in this folder have a different namespace.
For example if your default-namespace is MyNameSpace and you create a folder called Entity then all classes in this folder have the namespace MyNameSpace.Entity
And all Items in a project are compiled to one single dll or exe

Just add more classes to the project and put the data and behavior (methods) into the appropriate classes. The project will still build into a single exe or dll.
Generally, it's better to add a second project under the same solution call it "CommonLib" or something like that. Then you add it as a reference to the main application and set up the project so that the applications build depends on the libraries build. Add a using statement for the common lib where ever you want to use those objects. This is definitely better for large scale or enterprise applications. There's a pretty decent chance that somewhere down the line you'll want to reuse some of this code, if everything builds into a single exe that won't be an option.

How To Include Classes From Another Namespace In Assembly Instead of Writing Them Into A Separate DLL File?

I have a C# project with two namespaces. A GUI (Stoff3GUI as namespace) with the GUI xaml and .cs files, marked as starting object and a Library (Stoff3Lib as namespace) with all the classes doing the actual work.
Now, when I compile my code, I will receive a .exe file Stoff3GUI.exe and a .dll Stoff3Lib.dll. In Visual Studio, both namespaces are part of the same Project.
How can I compile the classes from the Stoff3Lib into the .exe file without producing a separated .dll file?
Edit:
Changed the xxx to my project name Stoff3 for better understanding.

If both namespaces are part of the same project, you should already only end up getting a single assembly.
This can differ with web project setups (various different flavours of web projects create assemblies in times and manners I've never understood) but for standalone executable projects, it really is "one project produces one assembly" in all cases as far as I'm aware. Double-check that you really only have one project - for example, you shouldn't have any references in the project to an xxxLib assembly.

I'm not entirely sure what you are doing here. It sounds like you might have a single 'Solution' with two projects My immediate thought is just to move the classes you want into the the GUI start project and delete the other project.

I believe what you really have is 1 Visual Studio solution with 2 projects.
Since a picture is worth 1000 words, and just to clear up terminology, here's what that looks like in VS2012:
The output of this solution is exactly what you describe:
TwoProjects\Stoff3GUI\bin\Debug\Stoff3GUI.exe
TwoProjects\Stoff3Lib\bin\Debug\Stoff3Lib.dll
The easiest way to accomplish what you want is to have a single VS project that contains 2 different namespaces. It's good practice to add folders that match your intended namespace structure, in your case Stoff3GUI and Stoff3Lib:
When you compile this solution, the output will be a single EXE, but you still maintain the separation of model and view namespaces very clearly in your folder/file structure:
OneProject\bin\Debug\OneProject.exe

How to override VS2010's automatic folder->namespace mapping in new cs files

Projects are often broken down into folders, and those folders are typically expected to map to code namespaces. However, in many of my core projects I have classes that I have merged into existing namespaces - for example I have an MVC reference library that adds additional types into System.Web.Mvc, or System.ComponentModel.DataAnnotations, for example.
In other projects, I might have a suite of interfaces and a suite of default implementations of those interfaces; so I might split the code files into two separate folders (e.g. 'Objects' and 'Interfaces') but I don't want to have Objects and Interfaces sub namespaces.
Equally, I often write extension methods for types in other libraries - e.g. System.String, which I merge into the System namespace so they are already 'there' as soon as you reference the assembly.
So given a project structure like this (in response to the first answer, this project is intended to produce a single assembly with all the namespaces; and could be a dll that might be signed):
Our.Core.Library
|->System
| |->StringExtensions.cs
|->System.Web.Mvc
| |->AnotherModelBinder.cs
|->OurCoreClass.cs
In the above, I want new files added to the root to be in the namespace Our.Core.Library, but I want new files added to the System and System.Web.Mvc folders to be in System and System.Web.Mvc respectively. But VS will give them a default namespace of Our.Core.Library.System.
It's a small gripe, but I'd like to be able to override the default namespace for a specific code folder so I can control it. Any ideas how to achieve this? I've tried an empty default namespace for the project, which might logically make it work for sub-folders, but obviously not for the root; however, the VS Properties page doesn't accept an empty namespace.
Ideally it would be a solution that I can easily replicate across our entire dev team to enable other developers to be able to add code files whilst adhering to the namespace structure set out at the architect/planning stage.

Every C# project settings has a Default namespace option in the application tab that you can change to any other value which will take effect when you add more files to the project. There is only one setting allowed per project
You can break your project into multiple projects and have the default be different for different projects

Basically the only way I'm going to be able to do this is to write my own extension to Visual Studio. It might even require it's own project or item wizard - if I can get anything working I'll post it up here in the future.