Our development sandboxes are currently running visual studio 2013 (update 2) and ssdt March 2014 release for our database projects. The latter was downloaded via the former.
I have started to look into tfs builds for the database projects. Our build box (controller and agent on the same box) is a windows server 2012 Standard with TFS 2012 installed.
I am trying to figure out what ssdt installs are required on the build box in order for msbuild to build and publish database projects - unfortunately I am not getting a clear picture.
Questions so far:
Is http://sqlproj.com/index.php/2012/03/headless-msbuild-support-for-ssdt-sqlproj-projects (still) relevant to our build box?
Do I have to install a visual studio shell to get ssdt March 2014 release? Or is there a standalone install?
Will ssdt March 2014 release suffice to get msbuild to build and publish?
The sqlproj.com article you referenced is still one of the better articles to follow. Note that right now it may be easier and better to install the VS2012 SSDTBuildUtilities.msi on your TFS 2012 build server. That is downloadable from the SSDT download page - the easiest way to get specific MSIs is to create an administrative install point which will lay them all out in a specific folder.
There have been a number of changes in the March 2014 release that require updates to the install recipe:
You need to use the SQL Server 2014 feature pack instead of 2012. The same MSIs are needed.
The expected install directory for the DAC and SSDTBuildUtilities compoments has changed. It's now expected to be under the Visual Studio install directory and will depend on having the $(VisualStudioVersion) environment variable set to match the VS version. If you're running TFS2012 the likely location will be "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120". You can confirm this by checking the targets file just as that article suggests
We are currently working on an improved TFS / Build Server configuration experience as this is clearly harder than it should be to set up right now, especially with the changes to DAC and SSDTBuildUtilities location. However we do not have a firm commit date on when this might be released.
Related
We are trying to upgrade our TFS 2013 Update 5 to TFS 2018 Update 2. I have checked this thread to make sure we meet the prerequisites.
From the list, it looks like we met the prerequisites, but when i run the TFS2018 installer it gives me an error saying there is no direct upgrade path from 2013 to 2018. Im not sure why we are getting this error when i looked at the Microsoft site, there is a direct upgrade from TFS2013 update 5 to TFS2018. What am i missing?
Here are our specs on our TFS 2013:
SQL: SQL Server 2016 SP2
OS: Windows Server 2012 R2
TFS: TFS 2013 Update5
P.S. we moved the databases to a SQL server 2016 from a 2014 SQL just to comply with the prerequisites.
Ahh yes, the added error message makes sense. What the TFS installer is telling you is that it can't perform the upgrade while TFS 2013 is installed and running on that server.
You first have to uninstall the Application Tier and Build Services on the machine. This doesn't impact your databases in any way.
Then you can install TFS 2018.2 or 3 directly into that server, point it to the existing SQL databases and it will ask you whether you want to upgrade those.
You'll need to verify a few server settings, plus decide whether you want to enable SSH and Search on this machine.
After the integrity check the installer will install the TFS Application tier and start the database upgrade process.
Only of you're on TFS 2005 or 20008 do you need to perform this step multiple times. first with the 2010 installer before you can take it to 2018. This is what's meant by 'not possible to do a direct upgrade' in some parts of the docs and which confused me at first.
I'm trying to import modified WITs to a existing project. But, It was showing the below error:
Microsoft.TeamFoundation.WorkItemTracking.Server.ProvisioningImportEventsCallback
Earlier it was working fine. But, now the issue started.
What could be the possible solution for this? I just wanted to upload WITs through Command prompt(witadmin.exe) only. Any hints/information would help
From your description, you are trying to use VS 2015 to connect to TFS 2017. Please check documentation Import, export, and manage work item types:
If you are connecting to TFS, you must use the same version of Visual
Studio or Team Explorer as TFS. For example, if you connect to a TFS
2017 instance, you must connect from Visual Studio 2017 or Team
Explorer 2017.
TFS 2018 and TFS 2017
Visual Studio 2017 or Team Explorer 2017 client:
%programfiles(x86)%\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
or, TeamExplorer, Professional or Enterprise in place of
Community, depending on the version you've installed.
You should install VS 2017 or Team Explorer 2017 to run this command. Although VS 2015 could run witadmin command against TFS 2017 sometimes, there would have unexpected issue.
However, I found the solution for this issue by myself.
Clear the Team Foundation cache from your server and the user system from the below path:
C:\Users\\AppData\Local\Microsoft\Team Foundation\7.0 (or 6.0)\cache
Delete everything from the cache folder and restart the server\system. Then Login to the server. Now, you won't get any error for uploading [WITs] using command prompt.
Follow the procedures as given in Microsoft Site.
https://learn.microsoft.com/en-us/vsts/work/customize/reference/witadmin/witadmin-import-export-manage-wits?view=tfs-2018
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.
We currently use TFS 2013.
I'd like to do a POC where I can create some build definitions in TFS 2015 where it would get the source from our existing TFS 2013 server. Once the boss sees how much easier it is to manage our builds from TFS 2015, I'm sure he'll give us the go-ahead with upgrading the existing TFS 2013 to TFS 2015.
Is this even possible?
You could write a PowerShell script or some batch files to leverage tf.exe in order to map a workspace / clone a repo (depending on whether you're using TFVC or Git) as part of a build. Or just put the tip of your source code into the "demo" environment and build from there. The latter option is going to be much faster.
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?