TFSSCExplorerExtension

FSSCExplorerExtension (Team Foundation Server Source Control Explorer VS 2010 Extension) is Visual Studio 2010 Extension Package that adds new features to the TFS Source Control Explorer window for TFS 2010. Most important new features are Drag & Drop support, Move and Branch functions even for multiple files selection and Merge from Sources feature.

I also released separate version for Visual Studio 11 Developer Preview here.

Java SDK for TFS

You will be able to extend TFS using Java just as easily as you can with .NET.  This is going to enable teams using Team Explorer Everywhere to fully customize their development environment – in Eclipse or outside.

The TFS SDK for Java includes the following:

• A redistributable JAR file containing the TFS API’s.  This is a the same Java code that is used by Team Explorer Everywhere in the TFS plug-in for Eclipse and the Cross-platform command line client.  It provides access to version control, work item tracking, build and other functionality in TFS from your own Java based application.   We ship this as a single JAR file containing all the code and Java dependencies to make is easy to include in your own applications.
• The native code libraries used by the TFS API. We have a small amount of JNI code in the API to handle functionality that is not natively supported in Java on all the platforms that we support (such as access to Kerberos for authentication, or integrating with Keychain on the Mac).  We are making this native code available, also redistributable and compiled for Windows (x86, x64), Mac (Universal), Linux(x86, x64, ppc), HP-UX (ia64_32, pa_risc), Solaris(sparc, x86, x64) and AIX (ppc).
• Full API documentation in Javadoc format.  This is the same code documentation used by our developers, written by our developers.
• Code Samples. The team are very aware that getting started with this large code base can be quite a challenge, therefore they have put together a bunch of sample code to try and get you started.  It includes: 
  • Sample custom check-in policy
  • Sample custom work item controls (including a Radio Button control, Simple Button control, File Source drop-down and a sample External Source drop-down)
  • A set of sample console applications utilizing build and version control capabilities
  • A series of simple snippets demonstrating many aspects of the API including Work Items, Version Control and Build access.
  • Instructions for building and an Ant based build script to get you started.

Why upgrade from Visual Source Safe (VSS) to TFS 2010?

recommendation to upgrade your SCM from Visual Source Safe (VSS) to using TFS and here are the 8 reasons for that.

1. Set of Services:

While VSS offers only version control service, there are many integrated services offered by TFS. Services offered by TFS include Work Item Tracking service, Build service and Source / Version control service as foundation services. These services generate data. Based upon these foundation services, are the dependent services, which consume the data generated by foundation services. Those dependent services are reporting service and team portal service.

Reporting service analyzes the data generated by foundation services and provides reports based upon those. Visibility to those reports as well as other collaboration features are provided by team portal, that is based upon the SharePoint technology. TFS is not only a source control mechanism but a complete set of Application Lifecycle Management (ALM) services.

All these services are integrated by design, so you get additional benefits. For example while you are checking in code which is part of source control service, you can associate a work item like a task or a bug that you have fixed in that code. This association will provide excellent traceability between the work that is assigned to the team member and the actual code that team member has created against that work. This traceability is both ways. We can safely say that the services provided by VSS are only 20% or less compared to those provided by TFS.

Algunas características de TFS 2010

 

• Folder versioning. Rapid refactoring often involves changing not just the code but also it’s structure. TFS Folder versioning supports this.
• Branching. Within an iteration/sprint each individual/pair/feature crew might want their own branch or branches in order to support parallel development across the team. TFS branching helps to support this and, importantly, to track what’s happening with branch visualisation and timeline tracking. Branches are now first class citizens in TFS 2010 and as such have fine grained permissions and capabilities.
• Shelving. This TFS feature allows a developer to “park” code in a sand boxed area on the TFS server such that it is safe, but won’t effect anyone else’s code or any builds. This can help with safely sharing code, including code reviews.
• Annotation. In a rapidly changing codebase annotation allows you to overlay who did what and when into the source code itself. This can help quickly identify exactly what lines of code were changed, by who, and for what reason, in a specific build.
• Check-In Policies. Rapid code changes and check-ins shouldn’t mean that code quality suffers. TFS check-in policies allow you to define a quality gate to ensure that all code reaches a certain quality before it reaches the repository. For example, specific unit tests have been run and passed and code has been associated with one or more user stories or tasks.
• Change Sets. Maintaining the context of a check-in becomes even more important with rapid, frequent check-ins. Why did that code get checked in? A change set identifies which files were checked in and what user stories or tasks were associated with the check-in. To be able to go back and understand why changes were made (e.g. these files were checked in to fix bug 23) can save considerable time and effort at a later point in the project.
• TFS Proxy Server. Allows a remote team to get versions of the code and checkout from a local cache, rather than having to traverse a WAN to the central TFS server.

TFS 2010 – Application Tier Version Control Cache Configuration details

The following applies to the AT cache only (the real proxy is close but not identical as it does not have access to the TFS registry)

The TFS registry is the first place we look for settings:

• /Service/VersionControl/Settings/FixedSizeBasedPolicy indicates a fixed size cache (in MB)
• /Service/VersionControl/Settings/CacheLimitPercent is the alternative (i.e. % of the available disk space occupied rather than fixed size)
• /Service/VersionControl/Settings/CacheDeletionPercent is how much of the cache should be deleted when the threshold is reached (think of it as hysteresis)
• /Service/VersionControl/Settings/StatisticsPersistTime is how often the statistics file is saved to disk (not so interesting)
• /Configuration/Application/DataDirectory indicates where the AT cache will live

We then validate those settings (or come up with default if not found).

1. If nothing is set, the default is CacheLimitPercent = 75%
2. If both CacheLimitPercent and FixedSizeBasedPolicy are set, FixedSizeBasedPolicy wins.
3. If CacheDeletionPercent is not set, it defaults to 20%
4. StatisticsPersistTime defaults to one hour (any value above one hour is acceptable).
5. DataDirectory can be overridden by adding a node in the web.config file like so (in which case it overrides the /Configuration/Application/DataDirectory setting):

<appSettings>

<add key="applicationDatabase" value="Data Source=dbserverhere;Initial Catalog=Tfs_Configuration;Integrated Security=True;" />

<add key="WorkItemTrackingCacheRoot" value="C:\Windows\Temp\TFTemp" />

<add key="traceWriter" value="false" />

<add key="traceDirectoryName" value="%TEMP%\\TFLogFiles" />

<add key="applicationId" value="GUID here" />

<add key="dataDirectory" value="E:\" />

</appSettings>

Important considerations:

• ·In an NLB environment, the TFS registry settings apply to ALL nodes, which is why the web.config settings take priority.
• CacheLimitPercent is a bit misleading in that if you have a 100GB drive and 50GB of other content, the TFS Cache can only use 50GB, so by default, the cleanup will occur when the cache reaches: (CurrentCacheSize + AvailableSpace) * (CacheLimitPercent / 100) = 50GB * .75 = 37.5 GB
• The Cache Cleanup can take a long time (hours on a very large drive) – so I would recommend changing the default Idle Time out on the Application pool to at least 60 minutes if you have a large cache and infrequent requests.

Fuente:http://blogs.msdn.com/b/girishp/archive/2012/01/21/tfs-2010-application-tier-version-control-cache-configuration-details.aspx

Build SharePoint Projects with TFS Team Build

Introduction

Microsoft Visual Studio 2010 provides a brand new set of tools for developing SharePoint applications. With these tools, developers can easily leverage the familiar Visual Studio environment and functionality to develop, package, deploy, and debug custom SharePoint solutions. Team development is also well-supported by these tools. You can check your SharePoint projects into Team Foundation Server (TFS) source control and build and package your projects in TFS Team Build. This article describes how to build SharePoint projects developed by the VS2010 using Team Build when neither Visual Studio 2010 nor SharePoint 2010 is installed on your build system. If Visual Studio 2010 or/and SharePoint 2010 are installed on the system, however, you can skip some of the steps below that patch the system with necessary dependencies.

1.  Prepare the Build System

To build and package SharePoint projects, several components must be installed on your system.

• Install TFS Team Build
  If your build system already has TFS Team Build installed on it, you can skip this step. Otherwise, install and configure Team Build on your build system. Both Team Build 2008 and Team Build 2010 can build and package SharePoint projects created in Visual Studio 2010.
• Install .NET Framework 4
  If you are using TFS Team Build 2008, you must install .NET Framework 4 because it is not installed by default. You can download .NET Framework 4 here:http://msdn.microsoft.com/en-us/netframework/default.aspx. After installing .NET Framework 4, update the build path of TFS to point to the location of .NET Framework 4 by doing the following:
• 1. On the Build system, navigate to: \Microsoft Visual Studio 9.0\common7\IDE\PrivateAssemblies;
  2. Open the TFSBuildService.exe.config file using Notepad running as Administrator.
  3. In the file, find the MSBuildPath setting in the AppSetting section.
  4. Set the path value to the location of.NET Framework 4. (For example, C:\Windows\Microsoft.NET\Framework\v4.0.21116);
  5. In the Windows Services console, restart the Visual Studio Team Foundation Build Service.

Creating a backup in Team Foundation Server 2010