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.
Related
I am new to TFS and I'm trying to add some custom library files that the whole team uses into Team explorer in Visual Studio. It's library files of Sahi Testing tool so that any changes made to the files can be seen on all machines. I have tried searching online but could not find exactly what I want. Help
Basically, you have the following options:
If you have Nuget Packages for the libraries, you do not necessarily have to add the packages to source control and restore them when you need them. See this link for details.
As an alternative, you can add libraries as binary files to source control so that each developer or build server can retrieve them together with the source code. It's a good practice, to add them to a special location so that they are located in one place and not spread over the solution. However, only use this approach for binaries that do not change too often. Otherwise, you might bloat your TFS database if the files are large and change very often.
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.
Here's my specific scenario: Using VS2010, Pex and TFS2008, generated moles files are getting automatically added to source-control (TFS).
Pex adds a "project_name.moles" file to your test project and then autogenerates 3 files at build time: project_name.Designer.cs, project_name.Moles.dll, and project_name.Moles.xml. I want to keep the *.moles files in TFS (it's source code) but I don't want the 3 generated files to be in TFS (they are still part of the project, but they are generated when first built on a new system).
There are two reasons I need this behavior:
1. It's not a good idea to store generated code in source-control (let's not debate the merits of that here).
2. Specially, the DLL file is BAD because every time someone builds, all moles files are regenerated and thus all files are checked-out and DLL files are checked-out EXCLUSIVELY (non-mergable) and so other people can no longer build on their local box.
The Pex/Moles team are working on this but the solution is still likely several months away.
Is there a csproj property that can be assigned to these project files so that they are in the project but not managed by version control? I don't mind hand-editing the csproj file.
Moles will not be adding any files to the project in the next version (v0.94). It will use MSBuild to generate the assemblies on demand.
I think it depends more on the version control tool than Visual Studio, as usually you can set up some kind of filters in your version control configuration in order to exclude some files/paths.
E.g. if you use Mercurial/Hg, you can (and should) edit your repository .hgignore file and specify e.g. to exclude all *.moles files and the whole sub-tree MolesAssemblies\*. I guess other version control systems have similar options.
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)
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.