I need to configure a build definition in TFS 2017 for a solution that is developed in VS 2005.
The agent server that execute Build tasks is configured with Windows Server 2012 R2, and it's installed VS 2005.
In a build definition, I have tried with a command line task, but it remains executing the compilation and it is canceled by time-out
Can someone please reference me documentation or indicate me how to do it?
Thanks a lot for your help.
Audberto
I doubt that you'll be able to get the "Visual Studio Build" task https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/visual-studio-build?view=tfs-2017 working, but you may look at the MSBuild task https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/msbuild?view=tfs-2017 since you have a little more control.
Since 2005 (along with 2008 and 2010) are end of life, I don't think you'll get much support from Microsoft to support your scenario in the built in tasks.
Related
We have migrated to TFS 2017 from TFS 2010.
While executing the builds, the builds are taking too long to get completed successfully.
Previously, in 2010, we use to use community build manager to execute the builds, in TFS 2017 do we have any such tools to queued up the builds to execute them all at once. Not just manually executing them one by one.
There are many reasons for this problem, eg hardware, software, bandwidth, size of the project... Please refer to below article to check that, it's still available for vNext build (Task based build process): Optimizing Team Foundation Server Build Time
In case if you installed earlier version of Visual Studio 2017 on your build agent machine, then you may have this problem. There are issues tracked in developer community site :
VS 2017 Build very slow
Slow compile times compared with VS 2013
In this case, you can try the solutions/workarounds mentioned in the issues, alternatively you can also try to install VS 2015 for the building.
I've searched for answers to my question on this forum and elsewhere, but so far unsuccessfully.
We are upgrading our toolset from VS2008/TFS2008 to VS2013/TFS2013. We now have TFS upgraded (phew!) but the big questions remaining are:
We have a single build agent using Team Build 2008 running on a Windows 7 x64 SP1 machine, with build results published to an old XP machine. Will the new TFS2013 server be able to work with it fully, or are we compelled to upgrade the build agent to Team Build as well? if so, does Team Build 2013 run on Windows 7 x64 SP1 or will we need a complete new server platform?
If we are compelled to upgrade the build agent to Team Build 2013, will/should our existing build scripts continue to work?
Can anyone advise?
The answer to your question is, "It depends."
The build system was totally redesigned in TFS 2010 to be based on Windows Workflow build process templates instead of MSBuild files. TFS 2010/2012/2013/2015 can all run old-style MSBuild files by using a build process template called "Upgrade Template". Whether they'll work immediately out of the box depends on how customized your MSBuild files are and what (if any) custom assemblies you're using. Custom assemblies may need to be recompiled, or may need code changes to continue to work.
TFS 2008 build agents do not work with TFS 2013. You will need to upgrade your build agents. However, TFS 2013 and 2015 build agents will both run on Windows 7 SP1, so you're good to go there.
The build system was revamped again in TFS 2015. My recommendation would be to get on TFS 2015 ASAP and skip the XAML build system entirely. The new build system is much easier to work with and can be extended with far less pain.
You are in a scenario with a fair amount of risk, especially if your business depends on your CI builds running regularly. Your best bet will be to do a test upgrade of your environment and validate what steps will have to be taken to ensure your builds continue to run against the Upgrade Template, or how much effort it will take to retire your MSBuild-based build templates and switch over to a newer build paradigm.
Regardless, I would strongly recommend making the move to TFS 2015 over 2013. Why go through the effort of upgrading from 2008 to 2013, only to still be a major version behind?
This question of FxcopCmd vs Code Analysis has been discussed in SO, but my question is a bit more specific. We use VS2012 for development and TFS 2010 for TFS Builds. My question is - Without having VS2012 installed on TFS, I wanted to know if VS 2012 version of Team Tools (FxCopCmd) could be installed on TFS 2010 so that I get same FxCopCmd output on both development env with VS2012 and TFS build as well? Today when I run Code Analysis in VS2012, the count of violations obviously is different from the count seen with FxCopCmd run as part of TFS 2010 Build. This is understandable due to version differences, though I ensured that both run with the exact same command line parameters. FxCopCmd references point to v4.0 .NET assemblies in both cases.
Can I just have VS 2012 version of FxCopCmd or Team Tools installed on TFS 2010 and would that provide same results as that of running CodeAnalysis on VS2012? (Code Analysis in VS2012 in turn uses FxCopCmd)
Can I just have VS 2012 version of FxCopCmd or Team Tools installed on
TFS 2010 and would that provide same results as that of running
CodeAnalysis on VS2012? (Code Analysis in VS2012 in turn uses
FxCopCmd)
Yes, this is possible. You will need to specify a CodeAnalysisPath property value that points at the correct path, but otherwise the only concerns should be around licensing, not technical issues.
I just started using Team Foundation 2010, but I'm connecting to the server with Visual Studio 2008 SP1. It's working alright, except I can't install Power Tools to include shell integration because for some reason it requires Visual Studio 2010.
1) Is there any way I can get tfpt Shell Integration without having to install VS2010 ?
Second question is... I installed VS2010 in one machine and used the power tools for awhile. But when I changed the server IP, shell extension suddenly stopped working... It tries to reconnect and fails. I tried executing this, with no success:
tf.exe workspaces /remove:*
But I don't know if it has anything to do with my problem.
2) What happened to the shell integration? how can i solve it ?
thanks in advance
In order to use the shell extensions you need to have team explorer 2010 running on your machine. Install team explorer 2010 and then the power tools and you are ready to go.
When you are not able to connect to the tfs server, the removal of the workspaces will also not happen. That action needs a connection to the TFS server. Has your password been changed lately? If so, you might need to update the stored windows credential (available through the control panel). To investigate the connection problems, you could navigate to TWA (http://myserverip:8080/tfs/web)
I'm trying to configure automated build of BizTalk 2009 projects using Team Foundation Server 2008.
We have a staging server which has BizTalk 2009 installed. I ran the Team Foundation Server Build Setup on this server, and it can build non-BizTalk projects OK. However, BizTalk projects fail to build. I suspected something was amiss when "Deployment" was not a valid build type! I tried copying various things over from a developer PC which has BizTalk and Visual Studio 2008 installed, but still couldn't get it to work.
I don't really want to install Visual Studio on the staging server, but without it the "Developer Tools and SDK" option in the BizTalk install is greyed out. I guess I need this in order for BizTalk projects to compile.
So, my question is can a BizTalk 2009 server be used as a TFS build agent to build BizTalk projects without having Visual Studio installed. If the answer is no, what's the smallest part of VS that can be installed to get this to work?
Randal van Splunteren answered on MSDN:
There is a BizTalk installable feature called 'Project Build Component' (under 'Additional Software'). You can select/unselect it during installation of BizTalk. . . . It allows for builds without Visual Studio.
Be aware that you can only build stuff. For generating MSI packages you will need a BizTalk server (remote or on the build server itself).