I have Visual Studio 2010 with Visual Studio 2010 Team Explorer. After I check in code, I can view the changeset number (View History).
I typically put in the Changeset number in the bug log system as soon as I fix something.
Now where/how do I get the build number? Is this a TFS admin thing? Where do I get started? Do I need to use MSBuild instead of using Visual Studio GUI?
Thanks for any help!
When creating a build definition, by default TFS labels each build with this format: $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
The Default Template's build number can be customized under
[build defintion] > Process > Basic > Build Number Format
However, you may want to check out Versioned TFS 2010 Build for more control over the build number format and automatic versioning of the assemblies (via AssemblyInfo.cs).
through gui:
right click on builds > view builds > tab to "completed"
build definition > all
quality filter > all
date filter > today
double click on the build of interest:
you should see the build number and changeset at the very top.
=========
When you commit you should use the dialog to associate your commit to a work item - this way you don't have to manually set any of this.
To get these details in msbuild the data can be retrieved using:
<Exec Condition=" '$(IsInTeamBuild)'=='True'" Command=""$(TfsTask)" history ../ /r /noprompt /stopafter:1 /version:W > "$(TemporaryFolder)\grab-changeset.txt"" />
<Exec Condition=" '$(IsInTeamBuild)'=='True'" Command=""$(TfsTask)" properties "$(MyMSBuildStartupDirectory)\all-companies-run-after-update.js" > "$(TemporaryFolder)\grab-properties.txt"" />
we use the above to extract: build#, branch, revision#
It seems that you haven't set up a TFS-build at all.Even though this will require some time to grasp as a concept & tailor a solution to your own needs, this is definitely worth the investment (or, the other way around, NOT using TFS build makes the whole investment into TFS a lot less worth it).This might be a nice starting point, there are a lot of useful resources out there, I 'd advise you to take a deep breath and dive right in. You can always return with more specific questions.
Related
I am setting up an automated build for my solution. However, I get errors regarding failures in copying certain information to certain folders. This pertains to build events that each project in my solution has.
What I was wondering is if there was a way to "turn off" the individual build events in the projects, or if there is a parameter to set somewhere that turns these build events off?
The automated build I have set up already does what the individual project build events are supposed to do, and so it is trying to repeat itself and is causing problems. I still need the build events to be associated with the projects because when they're running outside of the development environment, they need to occur for the application to function properly (the build events have to do with dynamically updating information).
Long story short, is there a way to turn off the builds that are associated with each individual project in my solution without actually deleting them? I need them to be there, I just need them to be "invisible" so-to-speak while I'm running the automated builds in the development environment.
I apologize for the verbosity and for the vagueness of everything, it is difficult to explain things sometimes without giving away too much.
EDIT: Not so much an edit as it is additional information for clarity, but nevertheless. The basic goal I am trying to accomplish is to disable the "post builds" that are associated with each of the projects in my solution. I want to keep them, just disable them while I'm running them through the in-house automated builds/tests
After loads of research on the "BuildingInsideVisualStudio" property, and lots of tweaking to get the syntax right, my team and I found what we were looking for.
We inserted the statement
if '$(BuildingInsideVisualStudio)' == 'true' <executed code>
format in the "Post-Build event Command Line" section under the project's properties > Build Events tab.
Some post-build script code like this should work:
if "$(BuildingInsideVisualStudio)"=="" (
#echo TFS build
) else (
#echo Visual Studio build
)
Place your existing code in the appropriate block depending on if you want it to run only in VS builds, or only in TFS builds
You can also change the .csproj file to something like this:
<PropertyGroup Condition=" '$(BuildingInsideVisualStudio)' == 'true' ">
<PostBuildEvent>commands to execute</PostBuildEvent>
</PropertyGroup>
Unfortunately, Visual Studio will not display any information in the Build Events tab, so it might be more difficult for future maintenance.
You could check any of the team build properties and see if they're populated. If so, you can assume it's a team build. I use this approach with our build so that post build deployment labeling etc only occur if it IS running on the build server.
Here's a link with the various team build properties
<SomeTask Condition="$(BuildDefinitionName)!=''">
Shamefully, we use TFS at work for a C# project. I wish we could move to svn or git, but we can't change that. All of us working on the project hate the automatic check-out "feature" of TFS, so we checked in our solution and project files as unbound from TFS.
Now, whenever we open the project, we get the following message:
The solution you have opened is under source control but not currently configured for integrated source control in Visual Studio. Would you like to bind this solution to source control now?
Is there a way to disable this message while keeping the solution unbound from the buggy and annoying integrated source control?
The message you reference has nothing to do with TFS, it has to do with integrated source control within Visual Studio. If you really want to get rid of this message, go to Tools->Options->Source Control and set your source control provider to "none."
Then, go and download the Team Foundation Power Tools and enable the shell access, and you'll be able to right click within Windows Explorer and check in from there. If you don't want to do that, you can do your check-ins from the TF.EXE command line.
But seriously, if you don't like the automatic check-out, then just turn that off. You have the option of having TFS automatically check out, prompt you for check out, or do nothing and leave the files in a read-only state until you explicitly check them out.
Another possibility could be to move to a 'git-tfs' combined solution. You would move your team to git, and sync with TFS on a regular basis. This way, only one person has to live with the TFS annoyances.
I have no experience with that, but apparently it has been tried before
If you like the svn/git model better, then I honestly wonder why you would want to turn off automatic checkout? You can configure VS to silently check out files on edit. This comes pretty close to the svn way of working, no?
Also, ensure that the TFS server is configured to allow multiple checkout on all text-based files, and you should be good to go. You can also install your own diff and merge tools (e.g. TortoiseDiff/TortoiseMerge) if you want.
Do I have some weird setting that is making this happen? I only want to change the text of a message box (and no other assemblies depend on that one) yet VS rebuilds all of my projects and it takes forever. Any ideas?
You can find out what is causing Visual Studio to think each project is out of date, and then address the issue directly.
Select Tools → Options → Projects and Solutions → Build and Run.
For the setting "MSBuild project build output verbosity:" select "Diagnostic".
Build.
You will get a huge amount of output in the output window detailing exactly what the build is doing. Before building each project it will print out why it thinks it is out of date. An example of such output is:
Project 'Foo' is not up to date. Input file 'c:\Bar.cs' is modified after output file
These "not up to date" messages should point you to the real cause of the unnecessary builds, which you can then fix.
There's some limited control over this without using Configurations if you check the option to only build startup projects and dependencies on Run.
Tools → Options → Projects and Solutions → Build and Run → Only build startup projects and dependencies on Run
You can exclude projects from your general build through the build menu..
Build → Configuration Manager → Uncheck projects that you don't want to always build.
This can massively speed up build time by only building projects that absolutely need to be built every time.
Note though you will have to build the projects that you've unselected independently (right click->Build on the project etc) if they need to be rebuilt.
You can also setup alternate build configurations so you can mix and match what will build when.
The play button is the start debugging feature.
Yes, Visual Studio will ask every project in the solution to build at that point. But note asking to build and actually building are different things. Asking to build merely says, about to do something build again if you would like. MsBuild will then do a bit of checking under the hood and decide if it should actually build the underlying project.
If your project is actually building then there may be some other problem going on. Can you give us some more info like language, project type, etc ...
It's also possible to change the setting 'On Run, when projects are out of date' to 'Never Build' instead of 'Ask'.
(its in the menu 'Tools -> Options -> Projects & Solutions -> Build & Run)
This way, you'd need to press F6 every time you make a change to build the out-of-date projects, but at least it will allow you to debug with F5 without the recompile.
I have to say this is not ideal, but it's something.
There was one issue though I had while using casini: The app-pool didn't recyle every time I press F5 because casini keeps running. You will have to manually stop casini from the icontray when you encouter problems but it's a major time-saver in contrast to rebuilding the entire site.
The "Play" button is probably not what you think it is, or you have incremental linking and the like turned off in your Project Settings.
In Visual Studio, I have custom MSBuild actions for various tiers - development, staging, testing, and so on. These scripts will automatically compile everything, do web.config swapping, and push code out to a location based on the chosen configuration. Usually when I want to run one of these builds on something other than development, I call the build script from the command line.
Though I try to be as diligent as possible, sometimes myself (and others working in the solution) will accidentally leave the configuration in one they didn't mean to - maybe they switched it to the "staging" configuration to view how the code looks with its specific preprocessor directives. Then they hit "F5" thinking they're in development to debug...and push busted code out accidentally.
So the question is, is there a way to still have the build scripts tied to the configuration, but disallow builds for certain configs from the IDE? Or pop up a warning? Or am I going about this the wrong way to begin with?
To have the staging build fail unless it's a Team Build, you should be able to use
<Error
Text="No Staging builds except on the Team Build server"
Condition=" '$(IsDesktopBuild)'=='true' And $(Configuration)='Staging' " />
CruiseControl.NET also passes distinctive properties to msbuild, so a similar idea would work with one of those in place of IsDesktopBuild.
I'm not aware of any differences in the default properties between a Visual Studio build and a command line msbuild one, but if you can bear a little extra typing, this should do the job
<Error
Text="You didn't say the magic word"
Condition=" '$(MagicWord)'!='please' And $(Configuration)='Staging' " />
then
msbuild /p:Configuration=Staging /p:MagicWord=please
Visual Studio won't include the extra property, so the build will fail.
Task Class for adding more control on MSBuild compile process.
In Team Foundation Server, I know that you can use the Annotate feature to see who last edited each line in a particular file (equivalent to "Blame" in CVS). What I'd like to do is akin to running Annotate on every file in a project, and get a summary report of all the developers who have edited a file in the project, and how many lines of code they currently "own" in that project.
Aside from systematically running Annotate of each file, I can't see a way to do this. Any ideas that would make this process faster?
PS - I'm doing to this to see how much of a consultant's code still remains in a particular (rather large) project, not to keep tabs on my developers, in case you're worried about my motivation :)
It's easy enough to use the "tf.exe history" command recursively across a directory of files in TFS. This will tell you who changed what files.
However what you're after is a little bit more than this - you want to know if the latest versions of any files have lines written by a particular user.
The Team Foundation Power Tools ship with a command-line version of annotate called "tfpt.exe annotate". This has a /noprompt option to direct the output to the console, but it only outputs the changeset id - not the user name.
You could also use the TFS VersionControl object model to write a tool that does exactly what you need.
If you install the TFS Power tools (at least for VS2005); it's called annotate.
It might be part of VS2008...
You can use TFS Analysis Cube to see generate a code churn report, which I believe is something you would like.
Annotate is now part of Visual Studio (I think it was introduced in VS 2010).
Docs
I'm writing an answer to an 8 year old question :). Its not really a full answer, but a suggestion to look into excel reports for TFS.
TFS2013 / 2015 on prem has something has an excel report that can be used to visualize Code Churn.
In VS open team explorer then select "Documents" then explode "Excel Reports". I believe Code Churn report has something like discussed. The report is made by some default project template so I think tfs2013 on prem just creates it.
Code Churn Excel Report VS2015
https://msdn.microsoft.com/en-us/library/dd695782.aspx
I had very similar requirement to get details of particular attribute in a file e.g. who added, when, related work items etc.; Following GitHub project is having implementation to get required details and required minimal changes to work with multiple files or project -
SonarQube SCM TFVC plugin
It requires analysis to be executed from Windows machines with the Team Foundation Server Object Model installed (download for TFS 2013).
This blog post is also having good explaination and sample application -
TFS SDK: Connecting to TFS 2010 & TFS 2012 Programmatically