I am new to TFS. (using TFS 2012 and vs 2008)I may be asking some very basic questions. How to make the TFS build fail when number of warnings is increased compared to the last build? I am willing to write vbscript/perl for it.
Finally I also want track also is there a new warning type compared to the last build?
If some guidance is provided.
Will it better be integrated as postbuild event?
Do i need to create a new Build Quality(in msft jargon)?
Check below article explaining how to do that. It has link to the Xaml file as well.
http://blog.stangroome.com/2011/03/28/fail-a-build-when-the-warning-count-increases/
You might be able to use something similar for your second question about warning type as well.
Related
I have done a bit of googling, and I cannot seem to find a solution.
I work on a VS 2013 project with 1 other person. Some times the developer doesn't check everything in, or has errors in the code. I do not always have the ability/authority to make the other developer to correct the errors.
How do I continue being able to compile the parts of the project I am working on, with out having to ask the other developer to check in or solve the errors.
Just to clarify, we are working on two separate forms/files that do not interact with each other. Is there a way to compile the current form I am working on, and run from the last successful build on the forms that have errors?
As the Title says,I am using TFS, and maybe that can be part of the solution?
Is what I am asking for possible?
You should implement a gated check-in build in order to prevent developers to check-in code that doesn't compile.
If they really want to put the code that is not complete in Source Control they should use the shelvesets.
I've been bumping into an issue lately where developers on our team (mostly me) have a tendency to open a project and forget to Get Latest Version before coding and we end up making new changes to old code.
It'd be nice if Visual Studio would know that I'm about to make new changes on old code and either warn me or automatically grab the latest version for me.
Is this possible?
EDIT: I forgot to mention I'm using TFS
Good question, and fortunately for you the answer is 'yes' (since you're using TFS as specified in your comment).
Go to Tools > Options > Source Control (on the left) > Environment and ensure 'Get everything when a solution or project is opened' is checked.
I must add, though, settings like this shouldn't really be used as a substitute for good habits and best practices. You and your team should be aware of the importance of 'get latest' to the point whereby you want to get latest and don't want to work without it (if you're at that stage in the project).
Potential 'downsides' to this:
On the odd occasion, you'll hear our team members say "don't get latest yet". Because of a bad check-in they've made. If they break the build - you'll get that broken build. Not an ideal scenario, it should never happen, but the reality is that it does. You lose an element of that control if it does it automatically.
Not to mention the fact that if your team are forgetting to get latest, there's an even bigger chance of them forgetting to check the changeset for potential issues. The 'resolve conflict' dialog doesn't always highlight every issue you need to be aware of.
I suppose a really minor downside could also be the start-up time of the project (one of the reasons Microsoft more recently got rid of this feature as you mentioned). You're not just opening a solution anymore, you're opening it and waiting for a get latest. Which could, then, require further attention (conflict resolution).
I'm possibly rambling now - but what about when you take on juniors that might not be familiar with source control concepts such as get latest? If it's always been taken care of, they might miss a trick. For example, hypothetically, VS opens but fails to connect to the TFS server as it's temporarily down. Could this cause an already forgetful team to explicitly get latest at a later date?
my team uses Visual Studio for our development environment, we like it very much
we use the same project files in our automated build
our problem is that it's so easy to make changes in visual studios UX that get applied to the project files. we're seeing frequent build breaks
...I know...I know... dont submit them to the repro!
I wish I could convince everyone to be more careful, but lets be honest - it's very easy given the number of permutations {x86,x64,any} {release,debug}
My question: Is there anything I can add to a VS project that would make it more difficult to make changes? I'm not looking for a perfect solution, but the UX in VS works great up until a point, and then I'd prefer notepad to keep mistakes down
I could make the file read only, I dont know how that would play with our source control but I could investigate.
I'm hoping for something clever, maybe a mode that would prompt for confirmation before changing?
ideas / tips?
Bring a piggy bank to the office. If a user commits a file that breaks the automated build, then that person has to add $1 to the piggy bank. At the end of the project, or when the pot reaches a particular amount, buy something for the team and print up a sheet showing how much each person "contributed" to the pot.
You should check visual studio for options so that check out and check in are explicit.
You can also add check in policies, which among other can demand that a clean build was done locally before checking in.
If you would like more help, you should add some information both about your current setup and what you would like to prevent and what you would like achieve.
I usually have the team lead check-out the project file and keep it locked. Then nobody else can check-in changes. It is a little lo-tech, but it worked each time we did it. A benefit to this approach is that, when a user tries to make a change to the project file, he/she gets a reminder right away (because it can't be checked-out).
If we need changes, the project lead makes the changes, checks-in and out right away.
I'm actually working on a tool that need some configuration before it can be used. To save some time a hard coded some values into the text boxes of the configuration tab, so I don't have to renter them every time I do some testing or debugging.
As we're using TFS to manage our solutions I'm wondering if there is a way to mark those hard coded elements in some way so that TFS or Visual Studio 2008 will remind me to remove/replace them before I do a check in.
UPDATE:
The todo comments won't be a real solution as we're already using it to mark code segments which have to be reworked. We use it as a reminder for longterm tasks. And we have plenty of them so this might become a little bit unclear.
Some options:
write a custom checkin policy
use the existing FxCop checkin policy and write a custom rule (if you're marking TODOs with something that gets actually compiled, like an Attribute)
ditto, but via the StyleCop checkin policy (if your TODOs are source comments)
Probably not the perfect solution, but Visual Studio let's you add TODO comments that may work well enough for you.
You could write a unit test that fails when the hardcoded stuff is found. Obviously, you won't get a reminder before checking in but you do get a build failure afterwards.
How can I figure out, how many files needs to be recompiled before I start the build process.
Sometimes I don't remember how many basic header files I changed so a Rebuild All would be better than a simple build. There seams to be no option for this, but IMHO it must be possible (f.e. XCode give me this information).
Update:
My problem is not, that Visual Studio doesn't know what to compile. I need to know how much it will compile so that I can decide if I can make a quick test with my new code or if I should write more code till I start the "expensive" build process. Or if my boss ask "When can I have the new build?" the best answer is not "It is done when it is done!".
It's really helpful when the IDE can say "compile 200 of 589 files" instead of "compile x,y, ..."
Could your version control tell you this? For example in Subversion "Check for modifications" will list everything changed since your last checkin (although not since your last build)
Mind you, doesn't "build" automatically do exactly that? (build only what's changed)?
Usually Visual Studio is good at knowing what needs to be compiled for you.
If you have multiple projects in a solution then just make sure your solution dependencies are set up correctly and it should just work when you hit Build.