Solution Output Directory

Question

The project I'm working on is being developed by several teams, where each team is responsible for a different part of the project. They all created their own C # projects and solutions, with configuration settings tailored to their own needs. However, now we need to create another global solution that will combine and build all the projects in the same output directory.

The problem I am facing is that I found only one way to make all projects embedded in the same output directory - I need to change the configurations for all of them. This is what we would like to avoid. We would prefer that all these projects not be aware of this “global” solution. Each team should retain the ability to work only with its own permission.

One of the possible solutions is to create a special configuration for all projects only for this "global" solution, but this can create additional problems, since now you need to constantly synchronize these configuration parameters with the usual one used by this particular command. The last thing we want to do is spend hours trying to understand why something doesn’t work when building under a global solution just because of some flags that the developers checked in their configuration, but forgot to do it in the global configuration.

So, for simplicity, we need some type of output directory or post build event, which will only be present when building this global comprehensive solution. Is there a way to achieve this without changing anything in the project configurations?

Update 1
Some additional details, I think I should mention:

We need this global solution to be as close as possible to what the end user gets when he installs our application, since we intend to use it to debug the entire application, when we need to find out which part of the application isn before sending this error to the command, working on this part.

This means that when building under a global solution, the hierarchy of the output directories should be the same as in the program files after installation, so if we have a folder Program Files / MyApplication / Addins, which contains all the addins developed by different teams, we need a global solution for copying binary files from addins projects and placing them in the output directory, respectively.

The fact is that the addin development team does not necessarily know that it is addin and that it should be placed in this folder, so they cannot change their relative output directory for the / bin / Debug / Addins assembly.

Answer 1

One very simple way is to create a solution. Include all projects and add a project (or more) to handle global solution build tasks. Then, the projects in the global solution should have a link to the projects that they need, and then let Visual Studio handle how to get the binaries from each project. They will (under normal circumstances) be copied to the output folder of the assembly project. Thus, a project added specifically for global build tasks will have a copy of all referenced projects

Another way is to create a global MSBuild script that references the rest of the build scripts. Each project has its own MSBuild script

EDIT

From the comments, it would seem that there are two categories of projects. One that needs construction, and one that does not.

For those who need to build, refer to them as projects in an aggregate project for those that do not require creation, add them either as links, or add dll as resources.

Using a later change in the assembly action property to No and copying to the Copy output directory if a newer one

In both cases, now you have all the dlls in the output directory, after which you can perform post-assembly in the aggregation project moving the DLLs that should be in a specific folder (i.e. not in the output folder)

Answer 2

The key point here is that the team is responsible for the delivery. This supplied set is a collection of binary files. Therefore, a “global” solution ... or a “product that uses the results from teams” is interested in all the “current results” working together. That is, you have the result of collaborative efforts.

So this raises a few questions. Does the team do what they consider to be an “issue.” It can be automatically in the build system. If it builds and all tests pass, publish it.

What you are looking for is a team publication or promotion release. The source code is how you got there, binaries are the result. Each command controls which binaries it considers release (this can be automated by the build system).

Not quite what you asked, but I hope this is an answer that leads to the right questions in order to give good results.

Answer 3

Take a look at the practice of continuous integration and use of the build server with scripts. This is an indispensable tool when developing various parts of the application as a team, and your problems are an excellent illustration of the reason.

Answer 4

You did not mention whether you are using a version control system. I found in practice that each developer supports the configuration of his / her own teams and creates them locally where there is a machine, since you do not check * .suo or * .user files, most of the personal configuration affects only an individual team member.

On a completely separate machine, check the same code from all repositories and compile the project on the build machine (this can be fully automated). This supports the independence of your build servers.

Do not worry that this is a “Solution”. You can easily create multiple solutions one by one.

Since the output path is relative (and probably "bin \ Debug"), it will be created wherever you check it. If you want all the binaries in one output folder, you could configure the output path for each configuration to match. Something like ".... \ bin \ Debug" (obviously, this affects where projects are created on local machines, but this may not matter). Thus, the same target output will be created for several projects.

You can also enable a separate configuration assembly on the assembly server, which is not located on each local developer machine, to package the final product.