Good practice for working with multiple solutions in Visual C # Express

Question

Background . My team consists of 3 rather inexperienced developers. We develop our own software for our company. We currently have several small and separate solutions. Many of them are interdependent. Currently, these definitions are made by referencing the output DLL in the corresponding release folder. Updates are reconfigured by manually rebuilding dependent solutions.

Example: Solution A uses the functions of solution B. The connection is made using solution A, referencing ... \ Release \ B.dll. Changes to B are propagated by building solution B, then building solution A, etc.

This worked fine, but now we are moving from the manual version control system (folder1, folder2, folder2New ...) to the correct one (git).

It seems that the version of the DLL is not recommended. This means that every time someone wants to create a new version of A, he also needs to build B (and possibly 5 other solutions) in order to have the latest version B.

I think there should be a better way to do this. I was considering combining the relevant solutions into one main solution, but I cannot figure out how to do this in Visual C # Express (which we use).

So in the end the questions are:

• Is there a solution for the wizard that creates everything you need? - seems to be from MSDN, but I can't figure out how to do this in Visual C # Express 2008, which robs me

• Is this possible in Visual C # Express? If not, what is a good way to solve the problem?

Change Thanks to everyone for the great suggestions below. Here is a summary of what I ended up doing.

In short, the answers to the questions: "Yes" and "Sort, but mostly yes." I implemented the following: to get an idea of ​​the dependencies, I did this, as suggested below, and drew a binary product map with an arrow pointing to the dll or exe name for all its dependencies.

For each project, I opened my corresponding solution (since at first there was one project project pr). Then I added the project file of each dependency in the tree structure displayed on the graph (by right-clicking on the solution in the solution explorer), so dependencies were included, etc. Then I deleted the old links (pointing directly to .dlls) and added links to the projects.

An important result is:

• When a project solution is built, all its dependencies are built with it, so when you deploy, you know that all the assembly products are automatically from the latest version.

Answer 1

I would create a new solution and add all the projects that are related to each other. You can group projects from each of the original solutions by placing them in different solution folders in the new solution. Thus, when you create a project, all the projects on which it depends will also be built. It also means that all your projects will be built using the same configuration (i.e. Release or Debug). This means that all of your projects can be built in Debug, and not just at the top of the dependency tree, and all below is the Release build. Makes debugging a lot easier.

Answer 2

You need to think of solutions as a “grouping of projects” - projects are what are actually “built” and not “solutions” (well, this is not entirely true, the solution turns into a “metaproject” that refers to the contained projects but its close enough to the truth)

If you have interdependencies between solutions, I would suggest drawing all the projects on a large board, and then drawing arrows representing the dependencies from project to project. As soon as you do this, you can immediately see what makes sense in the respective “project groups”. They become your decision files.

For example, if you have projects A, B, ..., F, where:

• A depends on B
• B depends on C
• D depends on C
• E depends on F

One of the possible sections here will be decision 1 with projects A, B, C, D and decision 2 with projects E, F.

Answer 3

I have Visual C # Express 2010, and when I create a new project, it automatically creates a default solution. If it is displayed, you can right-click on the solution and choose Add> Existing Project.

If the solution is not visible (it seems that I remember this problem in C # Express 2005/8), then you can add an existing project through File> Add> Existing Project. Now the solution should be visible.

In terms of sperm, I usually do the following:

All that needs to be built together should be in one solution, and these should be projects, not DLLs. I try to live The Joel List , where you can build your project in one step. If this is one deployable device, then there must be one solution. All my projects are built on the build server before they can be deployed, so everything should be in the solution that needs to be built.

The guys sometimes put the WCF services and clients project in one project for easy debugging, but it depends on whether you want to deploy the client and server yourself. Usually for large projects I share them.

Finally, there is one exception. We have a central shared library that is used by different teams. If it is included in various solutions, and one team changes something, we end up breaking other teams. In this case, we create a single solution with all library projects. They are created in the DLL where the versions are stored. We see them as a structure that other solutions can use. For example. Team A uses CommonLibrary 1.1, and Team B uses CommonLibrary 1.2.

Answer 4

I would come up with a common area to pop all DLLs. My company uses the "R" drive, which is only LOCAL (not a network, so no one can touch the folder of others). Each decision will be built on this. Right-click on the project, properties-> build and change the output. Or you can add a post build command to push the DLL there. After that, all your projects refer to this location.

Once this is done and everything points to the same place, you can add different combinations of projects to different solutions. If a developer needs only ui projects, they can open a special “ui” solution, which is a subset of the whole.

Here is the post build event that I use in my project properties -> build events

rem when building on local workstation copy dll to local R:\ if '$(BuildingInsideVisualStudio)' ( xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\ /Y ) rem if "Enterprise" build then copy dll to Corp R:\ drive and to Build Machine R:\ if '$(Reason)' == 'Manual' ( xcopy $(TargetDir)$(TargetName).* \\folder\$(TargetName)\1.0\ /Y xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\ /Y )