We are maintaining code for one of our clients.
Initially, we copied all the source code that they have and added it to our TFS 2012.
We modify the code any time they need a bug fix and give the client deployment packages.
Now, client wants all the latest code in their TFS 2012 as well.
Is there a way to update their source code with our changes? ...
preferably automatically (i.e. power shell script) and preferably with history of changes.
There are many approaches each with some pros and cons. The following are the main options I would suggest.
Database backup and restore
This is the only path that guarantees full fidelity. It has some technical difficulties (e.g. SQL Server version and editions) and political (how much information you care to expose, how much effort you want to put in sanitizing your data).
Project synchronization
There are some tools, most notably the Integration Platform, that use the API to read and reply the changes from one system to the other. It requires that the syncing tool can see both systems via HTTP(S).
It gives you the flexibility to project only some data (say source code not work items).
Keep in mind that you will always loose something in the process: the Changeset number will never match, some users details.
Dumb dump
Give up conserving full history and be content to share the code.
This is the simplest to implement: get all the code, ship and check into the other system. You can associate release notes in the check-in.
Two simple scripts using TF.exe is all you need.
You can use TFS Integration Tool to achieve the code migration(TFS-to-TFS). TFS Integration Tool moving data between two different servers. The migration is done through the APIs of TFS, and there also some limitations.(Check the above link for more info)
Detail steps please see my answer in this question: Move Team Project to another Project Collection TFS 2013
We have TFS 2012, and have a lot of projects created back in version 2008 of TFS.
Is there a way of finding the name of the TFS project template that was used when creating the TFS project?
Thanks,
Thomas
Short answer: no.
You may check the Work Item Types available in a project and infer the Process Template used, e.g. "MSF for Agile Software Development" had a "Quality of Service Requirement".
TFS Team Project Manager on CodePlex is a free tool which will inspect all your team projects process templates (even if they're customized) and tell you which process template was most likely used to create that Team Project (and give you a % confidence in the match). You can even give it additional "source" process templates, such as your company custom process template, and it will tell you which projects were created with it.
I found a way for finding the template name from a SQL query. However, this will only list those projects that were created in TFS2012
USE Tfs_DefaultCollection
SELECT tbl_projects.project_name AS [Team Project], tbl_project_properties.value AS [Process Template]
FROM tbl_projects INNER JOIN
tbl_project_properties ON tbl_projects.project_id = tbl_project_properties.project_id
WHERE (tbl_project_properties.name LIKE '%Process Template%')
I am having a problem where My Eclipse 9.1 is not able to connect to multiple projects in 2010 using the Team Explorer Everywhere plugin. If I try to connect a second project, it disconnects me from the first one. I can not find any way to be able to pull down multiple projects like I was in TFS 2008.
Any Ideas?
This is as-designed. Team Explorer Everywhere can only connect to a single Team Project Collection at a time. There are myriad reasons why this is the case, but all are to preserve the notion of atomic operations against the server. Some operations (for example, check-in) simply must be scoped to a single server instance in order to make sense.
Since a single changeset is atomic in TFS, an attempt to check-in multiple pending changes either all succeed or all fail. Consider if you had pending changes from two different servers: you cannot commit all these changes as a single changeset - one server could reject your check-in due to conflicts, while the other could proceed successfully. This is, at best, confusing, but most likely actually leaves your projects in an inconsistent state since there may be dependencies between these projects. Since there are distinct changesets for each server, the UI must reflect that.
After much deliberation and experimentation, we concluded that the best user experience is simply to have an experience where you can import projects from multiple TFS servers, but you must select which server you want to work with in the UI by selecting which one is currently "online". All TFS functionality is available for the online server which a limited subset of the TFS functionality is available to the other projects.
We would recommend that you consolidate your Java projects to a single Team Project Collection if you need to import all of them.
This behavior is unchanged from any previous versions of the software, including before the acquisition of the technology by Microsoft (when the product was still part of Teamprise Client Suite.)
Also note that the scope of commands available to "offline" projects has increased dramatically in TFS 2012 thanks to the new Local Workspace functionality.
I am starting work on a SharePoint 2010 Project and using the Visual Studio 2010 Built-In Magical Extension to do so. However, the turn-about cycle to re-deploy the solution is terribly long (build, package, retract, deploy, then restart, etc.) The only changes during this time have been to the individual Web Parts.
In the past I have used WSP Builder and for minor updates on the dev box just using the Copy-to-GAC/Copy-to-Hive features which has a much shorter turn-about to see changes to a Web Part. I was wondering if there was a similar (or alternative) method to get a similar quick turn-about in VS2010? The Mapped Folders address say, a changing view, but it's the Web Parts that interest me most now.
Please, if you are going to say "but you should always re-deploy", please do so only as a suggestion with other [useful] advice -- the testing servers get a full re-deploy. This is simply about helping me reduce the development cycle times.
Copy to 14 / Copy to GAC functionality in Visual Studio 2010
If you deploy the BIN directory rather than the GAC then you can just do a copy on postbuild - no restart/deploy etc needed.
Can anyone suggest the best deployment approach for VSeWSS 1.2 based development?
I have been working with this for more than 6 months now.. has anyone tried using WSPBuilder for this purpose?
I Personally prefer using stsdev (http://www.codeplex.com/stsdev). I've used both WSPbuilder and STSDEV. Stsdev offers some development project templates that you create using an stsdev gui, not like the standard project templates you create using new > project.
The stsdev projects has got a Rootfiles folder, which corresponds to the '12 hive' on the destination server. All the files you put into Rootfiles folder and subfolders, is automatically added to solutionpackage.ddf and manifest.xml, so you dont have to worry about editing these files and compiling them using makecab.
Another great thing that stsdev offers is build targets, like build, deploy, redeploy, Refresh Assembly in GAC, retract and upgrade. So stsdev projects automatically compiles the binaries, builds the .wsp package, and runs the stsadm commands according to the build type. You can customise the behavior of the build targets if you like, by editing the Microsoft.SharePoint.targets located in the DeploymentFiles folder of the project. As long as you are only working on the code, Refresh Assembly in GAC is a very fast build method, and you can see the changes in sharepoint immediately after.
An disadvantage of stsdev is if you use source control, the manifest.xml and SolutionPackage.ddf if not checked out, are read only, and will result in a compile error (i usually check out all the files in DeploymentFiles folder when working on a project). So you have to check out these files before building. Another thing is that it takes all the files under the Rootfiles, including the hidden vssver2.scc files if you are using source control. The project still builds and deploys without problems, but the files are in the wsp package, and copied to the '12 hive' on the destination server.
I think that compared to WSPbuilder, stsdev lets you customize just about anything of the development project, which i haven't been able to do in WSPbuilder.
You should do yourself a favor and look at VSeWSS 1.3. See Kirk Evans' blog for a good video overview: http://blogs.msdn.com/kaevans/archive/2009/03/13/sharepoint-developer-series-part-1-introducing-vsewss-1-3.aspx.
Major downside could be that it requires Visual Studio 2008.
I have been a STSDEV advocate, but am now leaning towards VSeWSS 1.3. My suspicion is that other WSPBuilder and STSDEV users will feel the same over time, but I haven't finished my evaluation of it yet.
We have always used WSPBuilder. This is best if you are looking to create wsp's.
It also provides a VS Add-in. You can build, deploy, upgrade etc. right from VS. Provides VS templates like Blank features, Web Part Feature, Feature with Receiver, Workflow feature, Event Handler, Item Template etc...
We manage 20+ projects with WSPBuilder
As Kirk Liemohn points out, you really should upgrade to VSeWSS 1.3. We took lots of customer feedback and there's lots of new features for developers in this version.
It includes quick deploy commands for deploying just the new binary or just the files into the SharePoint 12 folder structure. It also runs on x64 OS with Visual Studio 2008. It has command line support.
Available here
I prefer WSPBuilder as well. I don't have any problem with not being able to configure WSPBuilder the way I want it. In the latest version you can override its settings for each project or developer individually should you want to.
There is also a great add-on to WSPBuilder called SPVisualDev (codeplex.com/spvisualdev). Among other features it provides templates for adding ASCX files and it automatically pushes down files you have put in your project 12-hive folder from VS into the real 12-hive folder.. A huge time saver for me.
One downside to VSeWSS 1.2 was the lack of deploy to bin support. 1.3 adds that, but I haven't gotten it to work with referenced assemblies.
I've switched to STSDev 2008, a spinoff of the original STSDev with bug fixes. I've been working with the main contributors to add documentation to the project on CodePlex, but it's had 1900 downloads in little over a year.
I have used VSeWSS 1.2 and 1.3 and it does make deployment pretty easy. The question I had was, what do you guys usually do if you wanted to distribute the Web Parts to a customer administered SharePoint server.
Do you just take the Release folder and tell them to run the setup.bat script? Do you package it differently? Do you create custom installers?
VSeWSS 1.3 CTP is out now, and does have command-line support. That being said, the extensions are IMHO--and based on currently using them for a very large, very complex project--a pain in the rectum for the following reasons:
Every time you open a solution of extensions-enabled projects, you will have to sit and wait while the VSeWSS wheedles through each and every project, checking structure and trying to repackage each solution. The wait seems to grow exponentially with every extensions-enabled project you add to the solution. Given all of the waiting already included in doing SharePoint development inside a VM, the wait can be excruciating.
While VSeWSS is making its way through the projects, no indication is given of any work going on; VS simply becomes unresponsive.
Every time you close your VS solution with extensions-enabled projects, VSeWSS does the whole operation over again. Given that, by this time on my current project I'm usually 10 or so hours in the seat, and the last thing I want to do is wait longer to go home, this process is worse that excruciating (if that's even possible.) Most of the devs on our team just go to Task Manager and kill the devenv.exe. process rather than waiting.
We've had a very bad time of it trying to use the current (CTP) version of the extensions to do an integrated build. We've been having a number of problems using VSeWSS from the command line to do build and packaging of all of our projects.
In brief, use STSDEV. Setting up the folders is kind of a pain, but once you have everything scripted out, you're pretty much set.