We have a solution file that contains some solution folders: libraries, unit-tests, applications, etc.
With Visual Studio 2010 we can build only the projects of a given folder by right-clicking on it and using "build" or "rebuild".
This is perfect on the developers' workstations, and we'd like to do the same on the continuous-integration server which uses MSBuild.
So, can we build a solution folder with MSBuild?
Or will we have to create a dedicated solution for each folder?
The conclusion of the below responses is that there isn't any built-in way to do that, but some workarounds:
create a dedicated solution with only the selected projects,
use a dedicated csproj that will build the selected projects,
add a new project which will reference the selected projects in the existing solution file.
I've chosen to use a dedicated solution file as it is the less intrusive and tricky way, though not the more flexible (the dedicated .csproj solution should offer full control).
Yes, you can build Solutions folders using MSBuild.
msbuild "framework.sln" /t:First\Project:Build
will build the project in the folder called First. However, disk folders and solutions folders must match (I tried it for my solution where they don’t first).
So all you'd have to do is choose a project that has all the other projects in that folder as dependencies.
Also see:
MSBuild command-line reference
The short answer is:
Yes, if you want to build specific set
of projects (grouped together in a VS
solution) with plain MSBuild you will
have to create a dedicated MSBuild
.proj for each specific set of
projects you want to build.
You will not have to create (and maintain) Visual Studio solutions to support your build, but in the end it's the same (an MSBuild .proj vs. a Visual Studio solution).
I have a similar scenario with a set of 60+ .NET projects (.btprpj BizTalk). For developing in Visual Studio, these projects are currently organized in 12 Visual Studio solutions.
For automated build and deploy I created a set of 50+ MSBuild .proj scripts to target every single component (or set of components) I need.
MSBuild offers a lot of possibilities for automating all the stuff around the actual build of the Visual Studio projects (export from version control systems, etc.).
Related
I have a solution with a large number of solution level build configurations. Whenever I add a project to this solution, Visual stuido changes all of my configurations to build the new project. Is there a way to stop VS from doing this, or am I stuck reconstructing all my build configurations every time I add a new project to the solution?
I don't know of any solution within visual studio but you could do it by hand rather easily. Project files are simply xml files and solution files are text-based as well (and rather simple structured).
If you know how to handle MSBuild files (i.e. project files) you can even simplify them if you have many configurations.
This is the msdn article for MSBuild:
https://msdn.microsoft.com/en-us/library/wea2sca5(v=vs.90).aspx
What is common way of doing this?
Maintaining a separate build file (nant by example) costs time but Will not lock you in to Visual studio.
Do most developers build with the Visual studio solution or do they have to use the nant build file.
What are the best practices?
What I do is use the proj files rather than sln files. MSbuild processes them just fine.
This way you have the best of both worlds. You are not locked into VS, but you do not have to maintain 2 copies of your build files either
It depends on your project...
I have multiple solutions that i want to build as one product, so i use msbuild / nant to include them all.
Another reason to use a build file is when you have more actions you want to execute when the CI server builds the project and you don't want those actions to be executed when the developers build the solution (Copying files for deployment or setting assembly version for example)
In general, i think that unless you have a reason to use a build file, you can just use the sln file
If I have a visual studio solution with a multiple projects, from the projects how do I figure out which one will have all the dlls once the solution is built?
The reason is I need to copy those dll's for my custom written build app. I know in the Visual studio GUI, if I right click on the solution and go to Project Build Order, the lowest level item will be the project which will have the complete list of built dll's and referenced dll's. So is there any logic I can use to work this out through code?
You could write some code to read the solution / project files (the formats are not hard) and work out the dependency tree yourself.
However, a better approach is to change all the projects to output to a common \bin directory to start with by altering the build properties in Visual Studio. This avoids you having numerous copies of binaries in various individual project bin directories and makes life easier when it grows to a size where you need to split into multiple solutions.
A directory structure something like the following is often useful:
\bin (Common output directory for all projects)
\src (I usually keep the solution file in \src)
\ProjectA
\ProjectB
\lib (Common libraries, e.g. nunit or log4net etc)
Can someone briefly explain to me the difference between Visual Studio's solution file (.sln) and project file (.vcproj).
It seems to me opening either one open the correct solution/project in Visual Studio. Is one the super-set of the other?
Note: I am currently using Visual Studio 2008 working on a project that was brought forward from Visual Studio 2005 (I believe).
A solution is a set of projects. If you need more than one project in your software, then go with solutions. I.E.: A Class Library Project + A Web Application Project.
A project file typically corresponds to a single module: EXE or DLL or LIB. A solution manages a collection of project files.
A solution is a collection of projects. Visual Studio is made so that it cannot function without a solution, so if you open a bare project, it will generate the solution automatically (or try to find one).
One solution can contain zero or more projects. Everything is in projects, so a solution with zero projects doesn't contain anything at all besides the solution properties.
Visual studio keeps track of where the projects are used, so if you open a project file, it will open (IIRC) the last solution where it was used.
When you create a project from scratch, a solution is also created, but it's not shown until you add another project to it. It looks like you have only the project open, but it's actually a solution containing the project that is open.
Specifically project files are intended to contain the data required to build the files in the project into an exe or dll. This file is utilized by the local compilers or with systems such as Team Foundation system and server side build agents.
Solutions are a client (IDE) construct designed to manage collections of projects, which in effect is a collection of different build definitions and associated files.
Solution files are typically made up of multiple project files.
There are a number of other questions related to this topic:
Whats a good standard code layout for a php application (deleted)
How to structure a java application, in other words: where do I put my classes?
Recommended Source Control Directory Structure?
Structure of Projects in Version Control
I could not find any specific to VSTF, which has some capabilities like Team Build, integrated Unit Testing, etc. I'm wondering if these capabilities lead to a slightly different source layout recommendation.
Please post example of high level directory structures that you have had good luck with an explain why you like them. I'll let people vote on a "best" approach and I'll award the answer in a few days.
Here is one that I like:
Private; all of the current system deliverables
Documentation; a rollup of all the documentation across the solutions that make up the product, output would be MSDN style documentation from Sandcastle
Common; Visual Studio SLN that contains all the projects that are common across all the other solutions.
Tools; Visual Studio SLN that contains all the projects whose output is a tool. Example might be a console app that performs a set of administrative task on the larger system
Developer; each developer has their own folder which they can use for storing whatever they want
Specific Developer (1..n); this contains any build settings, scripts, and tools that this specific developer chooses to store in the source control system (they can do whatever they want here)
Specific Deliverable Solution (1..n); Visual Studio SLN that contains all the projects for a specific major deliverable
Common; solution folder that contains Visual Studio Projects that are shared within the current solution
UI; solution folder that contains Visual Studio Projects that define user experience
DataLayer; solution folder that contains Visual Studio Projects that define a data access layer
Services; solution folder that contains Visual Studio Projects that define web services
Tools; solution folder that contains Visual Studio Projects that define tools specific to this deliverable (executable utilities)
Tests; solution folder that contains Visual Studio Projects that contain unit tests
Public; all of the external dependencies associated with the system (eg. 3rd party libraries)
Vendor; dependencies provided by a specific vendor
Build; Visual Studio SLN that contains code associated with the build of the project, in our case mostly custom MSBuild tasks and Powershell scripts
Target; each successful build of the product as well as point releases
Debug; all of the debug builds that are output from weekly builds and continuous integration. Developers do not manually manage this directory
Build Number; a directory that corresponds with the current build number
Solution Output; a directory that contains all the build output for each of the projects in a given solution
Release; all of the release builds that are output manually when a milestone is reached
Build Number; a directory that corresponds with the current build number
Solution Output; a directory that contains all the build output for each of the projects in a given solution
Note: All solutions will have a Tests folder and unit test projects.
A few thoughts:
Very few files in the root of the tree. On a large team, set permissions so that no one can add new files to the root of the tree, without some kind of authorization.
The default workspace will contain:
Tools contains all executable code required to build & run unit tests, including your custom tools and scripts (perhaps assuming that Visual Studio and PowerShell are already installed on the machine).
ReferencedAssemblies has things you pick up from somewhere else, including things you buy or download and things someone on the team wrote but isn't part of this project.
If available, source code should be in here, too, so you can service it yourself. (If not available, you're taking a big riks.)
Source - all the source code, including project files.
Documents - items that are not used as part of the build, but are necessary for the proper functioning of the development effort.
Binaries - bits that have been shipped to customers, including .PDBs and other artifacts necessary for servicing. (On small projects, I fork the sources for each release, but normally a tag/label is a better choice.)
Elsewhere (e.g. $/personal) have a place for each person to do with as they please ($/personal/USERNAME). For example, my side projects go here.