Visual Studio: Change Build Configuration --> Auto Change Startup Project - visual-studio

I'm wondering if anyone has figured out a way to do this. Here is the scenario....I have a build configuration called "UnitTest". When I run my unit tests I need to change the startup project. I often forget to do that second step. My build is large and time consuming. So, when I forget to change the startup project it wastes time. I wonder if there is a way to automatically change the startup project when I change my build configuration?

We were having the same issue.
We have a huge solution with over 100 projects. For CI purposes we had to build everything which became a nightmare.
I found this which seems to be the solution. Still testing but so far it looks exactly what you need.
https://marketplace.visualstudio.com/items?itemName=TepperAmir.StartupProjects

Related

Is it possible to change the configuration of visual studio according to the startup project?

I am having one solution with multiple projects.
I am basically creating building blocks to build more complicated projects later on. These projects are sometimes dependent on one another, thought I am trying to keep it losely coupled.
It is sometimes necessary to debug one of the projects to test whether certain functions actually behave the way they should. ( I am going to create test projects for each individual project in the future. ).
Since they are all .lib files, everytime I make a certain project the startup project to test it, I need to switch the configuration properties to create a .exe file otherwise it wont run.
Is there a way to change the configuration of your projects based on what project is the startup project? So that I can instantly run this instead of manually changing the properties everytime I take a differnt startup project.
Your plan won't work the way you want. But I suppose you could add an extra project that can load the correct lib file and launch it. Then in the debug settings of each lib project specify that debugging will launch your extra project with the path to the lib to load as an argument.
It will require a small custom project, but will make your life easier. It'll look something like this in the debug settings:

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

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

Is it possible to avoid the build before running the unit testcase in visual studio or resharpher

Consider that i am changing only one test/unittest project, and if i try to run that it builds the unit test project(accepted) and all the other dev projects(which is not really required).
how can i avoid this? i have 100+ projects in the solution so each unit test case run taking really long time because of the project build.
Are you using accessors? MS accessors may force rebuilding all "accessor-dependent" projects, which in turn may force to rebuild all solution.
p.s. That should be comment to your answer, but i don't have enough rep points to add comments.

Incremental builds in VS2010

How can i turn on incremental builds in VS2010? I've noticed that my project rebuild everything each time i press build. Is there any option in VS to turn this on? Or should i modify *.csproj on my own?
Projects should build incrementally already (just make sure that you do Build instead of Rebuild). The best way to check if incremental building works is to run the build from the command line. The second time you build it should take almost no time.
If things are still getting rebuilt, then perhaps you've modified your projects in some way that's messing up with the build order. Looking at the build logs (via the /v option) can help you poinpoint what's going on.

TeamCity - non-trivial build sequence, please advice

I am tasked to improve quality and implement TeamCity for continuous integration. My experience with TeamCity is very limited - I use mostly TFS myself and have some experience with CC.NET.
A lot should happen within a build process... actually the build is already pushed into three different configurations that will run one after the next.
My main problem is that in each of those I actually would need to start multiple runners. For example, the first build step shall consist of:
The generation of new AssemblyInfo.cs files for consistent in assembly numbering
The actual compilation
A partial unit test run (all tests that run fast and check core functionality)
An FxCop run
A StyleCop run
The current version of TeamCity only allows to configure one runner ... which leaves me stuck with a lot of things.
How you would approach this? My current idea is going towards using the MsBuild runner for everything and basically start my own MsBuild based script which then does all the things, pretty much the way that TFS handles it (and the same way i did things back in the cc.net way with my own Nant build script).
On a further problem the question is how to present statistical information, for example from unit tests running in different stages (build configurations). We have some further down that take some time to run and want that to run in a 2nd or 3rd step (the latest for example testing database generation code which, including loading base data, takes about 15+ minutes to run). OTOH we would really like test results to be somehow consolidated.
Anyone any ideas?
Thanks.
TeamCity 6.0 allows multiple build steps for a single build configuration. Isn't it what you're looking for?
You'll need to script this out, at least parts of it. TeamCity provides some nice UI based config for some of your needs, but not all. Here's my suggestion:
Create an msbuild script to handle your first two bullet points, AssemblyInfo generation and compilation. Configure the msbuild runner to run your script, and to run your tests. Collect your assemblies as artifacts.
Create a second build configuration for FxCop. Trigger it from the first build. Give it an 'artifact dependency' on the first build, which is how it gets a hold of your dlls.
For StyleCop, TC doesn't support it out of the box like it does FxCop. Add it to your msbuild script manually, and have it produce an html report (which TeamCity can then display).
You need to take a look at the Dependencies functionality in the TeamCity. This feature allows you to create a sequence of build configurations. In other words, you need to create a build configuration for each step and then link all them as dependencies.
For consolidating test results please take a loot at the Artifact Dependencies. It might help.

Resources