How can I tell whether a solution needs to be built (meaning, a change was made since last build)? I use the Solution4 Interface
This related question has the answer you need, with examples
How to get notification when a successful build has finished?
"to figure out when a successful build has finished, you need to use a combination of the two build events:
OnBuildProjConfigDone and OnBuildDone"
In addition, you can also use
Solution4.Saved property
to check if the solution has changed since last successful build.
You should assume that on open, a solution needs to be built.
Related
I'm looking of a DTSX file that I didn't make, trying to get an overview of how it works. But I've noticed that every time I open up an Execute SQL Task or File System Task it checks out the dtsx from TFS. I haven't changed anything, so why does it always check out the file?
Because the dtsx file is overly burdensome and mixes UI and data/programming elements in the same backing file? winces
Without seeing the specific file, what I had noticed back when I used version control systems that subscribed to the checkout/modify/checkin pattern is that things such as package configuration, expressions, etc may get re-evaluated as you open tasks which I assume the TFS modify daemon in VS detects the file could get dirty and so checks it out to help you.
You'll also notice that if you run the package, sometimes it gets checked out and marked as modified. Which is totally fun as you get to play: what was I doing before I left my desk? Did I actually make a change or was I just looking?
Not helping matters is that the save action from visual studio always triggers two changes: version build (which is a monotonically increasing number) and the corresponding version guid.
Not an answer, but I can commiserate with your experience. The answer likely lies in the engineering minds in Redmond and was never publicly documented.
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'm building nuget in TeamCity and would like to append suffix "-pre" to version number when build is triggered by a checkin. And when build is triggered manually, I'd like to be able to provide a checkbox if this build should be a preview release or production-worthy.
I've got a Configuration Parameter created like that:
In this case I always have -pre added to the version number, even if I trigger the build manually and don't check the checkbox.
If I remove the value -pre from the default value of the parameter, then checkbox prompt works as expected. But when my build is triggered via a check-in, the system does not give me -pre suffix and I end up with a production release which should only be created manually.
Any way to implement what I need?
Alternatively I only want to publish nugets only on a manual trigger of the build and don't really care about pre-releases, but I can't seem to find any way to check if the build was triggered manually or via a check-in.
The first part is relatively easy, using a step to check the value of the checkbox and set a parameter based on it - Here I've used powershell but this could be done in bash (I've assumed powershell as you're producing nuget packages)
Note that I have reversed your logic a bit, but it produces the outcome you desire.
Define two varibles
Setup the checkbox
Setup two build steps
In the first step, test the parameter and use it to set another parameter
In the second step I'm proving the value has been set correctly
You should be able to use %ReleaseSuffix% when you need it.
Regarding your second requirement, I'm again going to make an assumption that you only want to publish a nuget package based on it being a Release build rather than a Pre-Release (if I've assumed this incorrectly let me know)
Conditional build steps based on a parameter value are something I've been tracking for a while now on YouTrack. This has been requested since 2011, but has still not made it in as a feature. I made this comment back in 2014 as a work around, but don't have the Java skills (you might) - My comment on YouTrack Issue
There is an alternative way to get this working, that might require some reworking of your build configurations.
If your "Publish NuGet" step is not triggered by anything (assumming it's triggered by the previous build finishing) then you could have a build step that
Checks the %ReleaseSuffix% parameter
Calls the REST API to trigger the build to publish the NuGet
It would potentially look something like this - just ensure you replace the highlighted bits
TeamCity Documentation
Hope this helps
Although the accepted answer here is very good, it does have a flaw; you will not be able to use the Assembly Info Patcher build feature, as this executes before the first step. Unless you wish to chain your builds together, setting the version in the first and using that in the second (yuck).
I have managed to find a solution which should give you the same results by tinkering with the parameters, setting them as follows:
The reason for using the "EmptyString" parameter is because without it, checked value defaults to "true".
I have tested this with manual triggers (release & prerelease) and VCS triggers (prerelease only), all functioning as expected on TeamCity v9.0.3 (build 32334).
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.
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.