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)
Related
We currently have a number of C++-based products that build under Visual Studio, and are maintained under MKS.
In order for our automated build system (which comprises a number of custom scripts) to increase the version number of the software it must first determine if any of the files within the project have been modified since the previous build.
The current method for performing this check is to check for changes to files in the directory tree below that containing the Visual Studio solution. This works well enough, but it completely misses those files that reside in other, e.g. shared/common, directories and have been added to the solution as existing items.
I know that this must be a common issue, so I'm wondering what are the usual techniques for managing this sort of thing. I realise that one option is for there to be no common source files, and instead have shared libraries, but that is quite a long way from the current reality. What I'm hoping to find out is that for A.N.Other source control system there are plugins that 'support' visual studio solution/project files, and will check for changes in the files included therein. I think if I had that ability then the problem will go away.
get from https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473
The standard setup for .NET solutions is that each assembly gets its
own bin directory to which it is copied along with the assemblies of
all its dependencies. If your solution contains an .EXE file and, say,
40 different assemblies. Does it really make sense to copy the
dependencies of each assembly to each separate build directory? The
target directory of the EXE should be enough. Another way to
accomplish roughly the same would be to give the assemblies common
output directories. That also avoids the copying. Some earlier
versions of Visual Studio did not support this well, so be careful. I
have, however, been using this approach with VS2008 for quite a while
without noticing any problems.
question - how to disable creating "bin" etc for all child projects? Thanks
Edit - there is a more comprehensive answer at Optimizing Visual Studio solution build - where to put DLL files?.
Create top level /bin/ folders above all your child projects. Then for each project, right click and go to properties. On the build tab, you can amend the "Output path" to point to your new top level bin with a relative path (e.g. ../bin/Debug or ../bin/Release). You should do this for each build configuration (e.g. Debug and Release).
This should result in each assembly being copied just once to the same location.
Note I've checked this procedure in VS2008 but I suspect it is similar in 2010.
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.).
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.