I have two solutions which have some common code, so I'd like to extract it out and share it between them. Furthermore, I'd like to be able to release that library independently because it might be useful to others.
You can "link" a code file between two projects. Right click your project, choose Add -> Existing item, and then click the down arrow next to the Add button:
In my experience linking is simpler than creating a library. Linked code results in a single executable with a single version.
A project can be referenced by multiple solutions.
Put your library or core code into one project, then reference that project in both solutions.
File > Add > Existing Project... will let you add projects to your current solution. Just adding this since none of the above posts point that out. This lets you include the same project in multiple solutions.
You can include a project in more than one solution. I don't think a project has a concept of which solution it's part of. However, another alternative is to make the first solution build to some well-known place, and reference the compiled binaries. This has the disadvantage that you'll need to do a bit of work if you want to reference different versions based on whether you're building in release or debug configurations.
I don't believe you can make one solution actually depend on another, but you can perform your automated builds in an appropriate order via custom scripts. Basically treat your common library as if it were another third party dependency like NUnit etc.
You can wild-card inline using the following technique (which is the way in which @Andomar's solution is saved in the .csproj)
<Compile Include="..\MySisterProject\**\*.cs">
<Link>_Inlined\MySisterProject\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
Put in:
<Visible>false</Visible>
If you want to hide the files and/or prevent the wild-card include being expanded if you add or remove an item from a 'virtual existing item' folder like MySisterProject above.
You would simply create a separate Class Library project to contain the common code. It need not be part of any solution that uses it. Reference the class library from any project that needs it.
The only trick at all is that you will need to use a file reference to reference the project, since it will not be part of the solutions that refer to it. This means that the actual output assembly will have to be placed in a location that can be accessed by anyone building a project that references it. This can be done by placing the assembly on a share, for instance.
Extract the common code into a class library project and add that class library project to your solutions. Then you can add a reference to the common code from other projects by adding a project reference to that class library. The advantage of having a project reference as opposed to a binary/assembly reference is that if you change your build configuration to debug, release, custom, etc, the common class library project will be built based on that configuration as well.
You could include the same project in more than one solution, but you're guaranteed to run into problems sometime down the road (relative paths can become invalid when you move directories around for example)
After years of struggling with this, I finally came up with a workable solution, but it requires you to use Subversion for source control (which is not a bad thing)
At the directory level of your solution, add a svn:externals property pointing to the projects you want to include in your solution. Subversion will pull the project from the repository and store it in a subfolder of your solution file. Your solution file can simply use relative paths to refer to your project.
If I find some more time, I'll explain this in detail.
It is a good idea to create a dll class library that contain all common functionality. Each solution can reference this dll indepently regardless of other solutions.
Infact , this is how our sources are organized in my work (and I believe in many other places).
By the way , Solution can't explicitly depend on another solution.
If you're attempting to share code between two different project types (I.e.: desktop project and a mobile project), you may look into the shared solutions folder. I have to do that for my current project as the mobile and desktop projects both require identical classes that are only in 1 file. If you go this route, any of the projects that have the file linked can make changes to it and all of the projects will be rebuilt against those changes.
Two main steps involved are
1- Creating a C++ dll
In visual studio
New->Project->Class Library in c++ template. Name of project here is first_dll in
visual studio 2010. Now declare your function as public in first_dll.h file and
write the code in first_dll.cpp file as shown below.
Header File code
// first_dll.h
using namespace System;
namespace first_dll
{
public ref class Class1
{
public:
static double sum(int ,int );
// TODO: Add your methods for this class here.
};
}
Cpp File
//first_dll.cpp
#include "stdafx.h"
#include "first_dll.h"
namespace first_dll
{
double Class1:: sum(int x,int y)
{
return x+y;
}
}
Check This
**Project-> Properties -> Configuration/General -> Configuration Type**
this option should be Dynamic Library(.dll) and build the solution/project now.
first_dll.dll file is created in Debug folder
2- Linking it in C# project
Open C# project
Rightclick on project name in solution explorer -> Add -> References -> Browse to path
where first_dll.dll is created and add the file.
Add this line at top in C# project
Using first_dll;
Now function from dll can be accessed using below statement in some function
double var = Class1.sum(4,5);
I created dll in c++ project in VS2010 and used it in VS2013 C# project.It works well.
You can host an internal NuGet Server and share the common libraries that will be shared in other projects internally and externally.
Further on this read
There is a very good case for using "adding existing file links" when reusing code across projects, and that is when you need to reference and support different versions of dependent libraries.
Making multiple assemblies with references to different external assemblies isn't easy to do otherwise without duplicating your code, or utilizing tricks with source code control.
I believe that it's easiest to maintain one project for development and unit test, then to create 'build' projects using existing file links when you need to create the assemblies which reference different versions of those external assemblies.
One simpler way to include a class file of one project in another projects is by Adding the project in existing solution and then Adding the DLL reference of the new project in the existing project. Finally, you can use the methods of the added class by decalring using directive at the top of the any class.
As of VisualStudio 2015, if you keep all your code in one solution, you can share code by adding a shared project. Then add a reference to this shared project for each project you want to use the code in, as well as the proper using directives.
Now you can use the Shared Project
Shared Project is a great way of sharing common code across multiple application We already have experienced with the Shared Project type in Visual Studio 2013 as part of Windows 8.1 Universal App Development, But with Visual Studio 2015, it is a Standalone New Project Template; and we can use it with other types of app like Console, Desktop, Phone, Store App etc.. This types of project is extremely helpful when we want to share a common code, logic as well as components across multiple applications with in single platform. This also allows accessing the platform-specific API ’s, assets etc.
for more info check this
