Visual Studio: How to manage shared code between projects

Question

This has probably been posted before, but I'm not sure what search queries to look for!

Short description.

I have code that is shared between several projects. This code is still incomplete. The problem is that whenever I need to update this code, I do not want to do this 3 times, it will become a nightmare.

Is there any way to add it to the project without copying it to the project folder? those. I want a common class to be connected with my 3 projects as

C: \ code repository \ sharedclass.cs NOT \ eachproject \ bin \ sharedclass.cs

Do I need to create it as my own library project? It would be much better if the compiler could compile it as "external" code.

Greetings.

Answer 1

It is better to extract the common part into a separate library of projects and add a link to this project in all projects that depend on solutions / dependent ones.

Otherwise, you can add the code / file / element as a link .

Answer 2

As already mentioned, you can simply right-click your solution in the solution explorer, select Add> Existing Project and view the overall project .csproj file and it will be included in the solution from its original location.

There are two problems with this, but it may or may not be a problem, depending on the size of your team:

1 - a common project will be included in each solution with a relative path to the solution file (IE: ... \ CommonProject \ Common.csproj). This means that all developers must have the same working file structure or they will get errors when trying to open the main project.

2 - In the scenario, the general project refers to several projects (say, two - A and B), and the developer working on project A must make changes to the general project as part of his task. The developer will not be able to find out if the changes made by them will violate project B without actually checking project B and compiling it. As more and more projects refer to a common project, the risk of this event increases to such an extent that it becomes unmanageable.

Again, as others have said, there is no “right” way to do this, however, the approach I did is as follows:

1 - Use continuous integration, such as Cruise Control, to manage the construction of projects and put the overall project as a separate project on the server.

2 - Create a directory under your source code to create built-in shared DLLs. Select this directory on your build machine and whenever a shared project is created, it copies the output DLL to the DLL folder and commits these changes to the original control.

3 - Use environment variables on all development machines and the build server to control the location of the shared DLL folder and reference the DLL using this variable, and not the hard-coded path. (IE: instead of C: \ Source \ MyCommonProjectDLLS \ Common.dll, use $ (MyCommonLocation) \ Common.dll with the variable "MyCommonLocation" set to C: \ Source \ MyCommonProjectDLLS)

4 - For any project that refers to a shared DLL, configure the CI trigger on the build server for this project to view the shared DLL folder. Whenever changes are tied to it, the build server must then build all consuming projects.

This immediately lets you know if you are committing a change violation for any other project. The only drawback is that in this model consuming projects force updates to be shared into the common DLL as soon as they are created. An alternative is the version of the Common DLL from the revision of the source code when it is created and the placement of each version in its own subdirectory in the shared folder DLL. So you get:

Common DLLs
-1.0.0.1234
-1.0.0.1235
-1.0.0.1236

Etc. The advantage of this is that each project can then choose when to accept updates to the common DLL, simply referring to the new version of the code. However, this shortens both ways, as it may mean that some projects stay with older versions of the common code longer than they should, which may increase the work when it comes time to make these changes.

Hope this helps.

Answer 3

Yes.

You can add a project from anywhere on your hard drive to the solution. So put the common code in the class library and add it to the three projects.

Answer 4

Microsoft supports the open source project, which is now built into VS, it is called NuGet, you can display your common project as a nuget file and consume it in other projects.

It will actually expand all the files that you specified in the package after the build.

This is how .Net now supports dependencies. You will notice that even things like EF come through NuGet packages. You can even post it for free in places like MyGet.org, I use it and it works pretty well.

http://nuget.org/

Answer 5

Yes, put the code you want to split into a separate project of the class library, create it and refer to the DLL created from this assembly in your other projects.

Answer 6

I use git submodules to achieve this.

• Create a new git repository for each module (project) that you want to share between solutions. I usually also use unit tests for this project in a separate project, but in the same git repository.
• Add a submodule to the git repository of the solution that will use the generic code. Adding a submodule creates a link to a specific commit of the external repository. When the code in the submodule is updated, you can pull the updates into the parent solution, which is essentially the same as updating the link to commit the submodule. I find the process easier to visualize with an application like SourceTree .
• Adding a submodule and retrieving the last commit will create a copy of the shared project inside the parent folder of the solution. Import the project into the parent Visual Studio solution by right-clicking it and selecting "Add Existing Project."
• Add a link to the shared project in other projects that will use it by right-clicking on the project and selecting “Add Link” and selecting the shared project on the “Solution” tab.

Now that the overall project is included in the solution, you can click and pull the changes into the submodule, and these changes will be automatically included in the solution. You can also see changes in other git repositories that reference the submodule.