Possible to store build configuration in a file other than solution file? - visual-studio

I work with a solution that has a lot of projects in it. I created a new build configuration to speed up working with it.
To speed up compiling, I set most of the projects not to build in my new build configuration.
To speed up debugging, I set most of the projects to build for release in my new build configuration.
This is great, until I have to check in a change to the project file, or get the latest from someone else's changes to the project file. It is painful to merge the changes, or shelve and unshelve them constantly.
Is it possible to store my build configuration in a separate file? Ideas for workarounds welcome.

To answer the question directly: no you cannot store your config in a seperate file. Unless that seperate files is also a solution file of course. But there are some workarounds, all stored locally on your machine (too long for a comment so I'm posting an answer anyway):
I set most of the projects not to build in my new build configuration
just build them once, then unload the projects so they will not be built again. These settings are stored in the .suo file.
if you insist on keeping a seperate build configuration: ask the team if it's ok to push it into the source control, maybe others can benefit from it as well?
or write a script to transfrom the original solution file into one having our build config. That can be as simple as applying a patch, which you should keep up-to-date
To speed up debugging, I set most of the projects to build for release
write a script to delete the pdb files of those projects
for C++: add all namespaces of those projects to the natstepfilter file

Related

How to set up and maintain directory structure in TFS build server?

So I have this pretty huge solution with many projects, few of them use dlls from other projects in this solution, some projects copy files to other directories after build is performed. (as post build events)
when I build the solution locally on my machine, everything is great and working, but when i configure a build, and build it on build server (we use TFS) something goes wrong and i get a an error when i try to load one of the applications in this solution. (the error does not give me much data on what went wrong)
so before i sit to debug all of this. does anybody know how can i smartly manage all the build actions that are performed locally and via build server and see the deltas?
I would like to be able to build the solution exactly the same on build server as i do on my machine (with directory structure, post build events..etc)
thanks a lot
The generally accepted way to do what you're after is to use NuGet for managing your assembly references. You can publish your dependent assemblies into NuGet as part of a continuous delivery process, then reference (and update!) those dependencies in the solutions that consume them as necessary.
This removes ambiguity ("What version of Foo.dll is Project X using?") and reduces runtime errors ("Why is Project X using Foo.dll 3.0? It was never tested with 3.0! It needs to run with 2.7!").

Build dependencies and local builds with continuous integration

Our company currently uses TFS for source control and build server. Most of our projects are written in C/C++, but we also have some .NET projects and wouldn't want to be limited if we need to use other languages in the future.
We'd like to use Git for our source control and we're trying to understand what would be the best choice for a build server. We have started looking into TeamCity, but there are some issues we're having trouble with which will probably be relevant regardless of our choice of build server:
Build dependencies - We'd like to be able to control the build dependencies for each <project, branch>. For example, have <MyProj, feature_branch> depend on <InfraProj1, feature_branch> and <InfraProj2, master>.
From what we’ve seen, to do that we might need to use Gradle or something similar to build our projects instead of plain MSBuild. Is this correct? Are there simpler ways of achieving this?
Local builds - Obviously we'd like to be able to build projects locally as well. This becomes somewhat of a problem when project dependencies are introduced, as we need a way to reference these resources or copy them locally for the build to succeed. How is this usually solved?
I'd appreciate any input, but a sample setup which covers these issues will also be a great help.
IMHO both issues you mention fall really in the config management category, thus, as you say, unrelated to the build server choice.
A workspace for a project build (doesn't matter if centralized or local) should really contain all necessary resources for the build.
How can you achieve that? Have a project "metadata" git repo with a "content" file containing all your project components and their dependencies (each with its own git/other repo) and their exact versions - effectively tying them together coherently (you may find it useful to store other metadata in this component down the road as well, like component specific SCM info if using a mix of SCMs across the workspace).
A workspace pull wrapper script would first pull this metadata git repo, parse the content file and then pull all the other project components and their dependencies according with the content file info. Any build in such workspace would have all the parts it needs.
When time comes to modify either the code in a project component or the version of one of the dependencies you'll need to also update this content file in the metadata git repo to reflect the update and commit it - this is how your project makes progress coherently, as a whole.
Of course, actually managing dependencies is another matter. Tons of opinions out there, some even conflicting.

Validate C# project file against a template during build

I know that you can create a template project to ensure that certain required settings (for ex: code analysis, treat warnings as errors, platforms, etc.) are set in a new project.
I want to enforce this as a part of the CI process i.e. in the build I want to validate the C# project files against a template (or an XML file) and cause a build failure if the project files don't conform to it. I need suggestions and ideas on how this can be achieved.
I want to try this with TFS 2010 and VS 2010.
I am writing a custom task to search for all the C# project files and compare the Xml structure of the Template project file with the Actual project file and report any difference as error.
I usually tackle this by customizing my build process to run Code Analysis/StyleCop/etc against all projects regardless of project settings.
Likewise for Treat Warnings as Errors. I just override the proejct settings at the build-level so that no matter what people do to the projects I know that everything I want to run is being run at build time.

Visual Studio 2010: How can I build a project and not its dependencies?

I want to be able to build a web project and not its dependencies since I know that I have not modified any of the dependencies since the last build. I am looking to cut down the build time if possible. Is there a way to do this?
You could have a solution by
check the setting in Tools >> Options >> Projects and Solutions >>
Build and Run setting : Only build startup projects and dependencies on Run.
OR
If you want to go for sophistication then :
build >> Configuration Manager
from the "Active solution configuration:" dropdown select ""
give a name to your configuration and keep checked the "Create new project configurations" checkbox.
and then choose that config that you want and set the build or not check boxes.
To accomplish this in something I am working on, I created my own solution, added the projects I needed (including the projects I never wanted compiled), and then in the Configuration Manager turned off the check boxes for building the projects I didn't want to build, just as arora described above.
I've also made a copy of an existing solution (that had 16 components in it), saved it under new name (foo.sln -> foo.mine.sln), and then disabled the build of all the other sub-projects except the one(s) I am working on, that way I know for sure that I got the correct build settings.
It's not the simplest solution, but it works well for me, and takes less than 2 minutes to set up and is easy to understand. I normally add the new solution to the version control ignore list so that it never gets checked in.
Rather than project references you can just add the references to the dlls directly (the Add Reference dialog has tabs for these types, choose browse rather than project and remove the other projects from your solution). I typically create a full lib and web project solution for major development. Then just a solution for the website project for fixes where I don't need updated libs/dlls.
Although it is nice to have them autocompile if they have changed during heavy development. If they haven't changed it just refreshes them and recopies them to the bin folder.
Well one way would be to remove project references. Instead stick to dll references. You could use a post build script for dependent projects that copy the updated dll to the web project whenever they change.

CruiseControl.NET, Visual Studio & SubVersion

I am setting up a Continuous Integration server.
I have one issue that doesn't seem to be mentioned in the tutorials.
I have a ASP.net Web Application that I need to compile and them publish.
My Problem is that I seem to be able to compile the app but when I attempt to use a buildPublisher this copies every thing including .svn files & folders and ms CS files.
I am using an MSBuild task to compile my source. I tried setting my MSBuild Output Directory to directory but this didn't seem to have any effect.
What am I not understanding?
Thanks
You're probably looking for the _CopyWebApplication directive:
http://blogs.msdn.com/nmoreau/archive/2007/01/26/deploying-web-application-projects.aspx
We use CruiseControl.NET to deploy our ASP.NET applications to our test servers for the QA department so this is indeed possible.
In each project we created an additional build configuration called 'Deployer' which is identical to the Debug configuration with the exception of building an additional Web Deployment Project. So by running MSBuild in the Deployer configuration we can generate our compiled output in a known location.
We then use NAnt to perform a simple copy operation to the required location, i.e. into a folder where our IIS server is configured to look for the applications.
I know you don't mention NAnt in your question but it's well worth getting familiar with it if you want to get the most out of CCNet.
I'm not at work at the moment but if this makes any sense and you want some additional information then let me know and I'll pull some more information together.
Hope this helps
Are your bin or obj folders checked into svn? if so that would contribute or possibly cause this issue.
Because those folders shouldn't have any svn folders/files
You can configure SVN to call the .svn folders _svn instead.
Set the SVN_ASP_DOT_NET_HACK environment variable.

Resources