Setting up TFS Build 2010 for SharePoint 2010 Projects and Private MyGet Feeds

Recently, I set up our TFS 2010 Build Server to be able to build SharePoint projects and to leverage our private package feed on MyGet  for custom framework components used in our SharePoint projects. It wasn’t as straightforward as I thought and I had to leverage MyGet support from Xavier Decoster to finally hammer things out. (Thanks for your help, Xavier!)

To do this, there are two general one time setup tasks which needs to happen on the TFS 2010 Build Server. These are:

• Setup Build Server to Build SharePoint Projects
• Configure Package Sources to the Private MyGet feed on the Build Server.

Once the setup is finished on the Build Server, you will be able to create build definitions for your SharePoint 2010 projects and even specify for the build server to also package a WSP automagically.

Finally, Xavier Decoster outlined a few check list items in our correspondence back and forth. I thought it might be worth noting these in this blog entry, too. Xavier had mentioned that much of this information is scattered and will be consolidating the guidance on the MyGet blog…stay tuned there.

So here we go…

Setup Build Server to Build SharePoint Projects

SharePoint projects reference SharePoint Server 2010 assemblies which must be present on the build server. One option is to install SharePoint Server 2010. Another options is to copy the following assemblies from your development machine to a Reference Assembly folder on the build server:

• Microsoft.SharePoint.dll
• Microsoft.SharePoint.Security.dll
• Microsoft.SharePoint.WorkflowActions.dll

On the development machine, the above assemblies are typically located at

c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

and it is recommended to be copied to the build server in the folder

..\Program Files\Reference Assemblies\SharePoint\

Modify the registry to specify the reference assembly location. On a 64 bit Windows Server 2008 R2 Standard machine, add a key named SharePoint14 in:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx

and specify the location where you copied the assemblies to in the step above.

Copy the following assemblies to the GAC of the build server (these are located in c:\Windows\Microsoft.NET\assembly\GAC_MSIL on the development machine):

• Microsoft.VisualStudio.SharePoint.Designers.Models.dll
• Microsoft.VisualStudio.SharePoint.Designers.Models.Features.dll
• Microsoft.VisualStudio.SharePoint.Designers.Models.Packages.dll
• Microsoft.VisualStudio.SharePoint.dll

Finally, for build and package of SharePoint projects, the following custom target and tasks must be copied to the build server:

• Microsoft.VisualStudio.SharePoint.Targets
• Microsoft.VisualStudio.SharePoint.Tasks.dll

The files above are located in ..\Program Files\MSBuild\Microsoft\Visual Studio\v10.0\SharePointTools on the development machine and should be copied to ..\Program Files (x86)\MSBuild\Microsoft\Visual Studio\v10.0\SharePointTools on the Build Server.

 

Configure Private MyGet Package Sources

If you are setup like we are, you likely do not have Visual Studio installed on your build server. If this is the case, you will have to specify your MyGet private feed as a package and source and specify an account which has access to this feed. The following steps guide you through using the command line to do this:

• Start a command prompt and specify to run as the build service account. Provide the password for the build service account when prompted.

runas /user:DomainName\[TfsBuildServiceAccountName] cmd

• Run the following NuGet commands under the build service account

nuget.exe sources add –name [friendly feed name] –source [url to your private MyGet Feed]

nuget.exe setapikey [apikey] –source [url to your private MyGet feed]

nuget.exe sources update –Name [friendly feed name]-User [username] -pass [password]

 

 

Specify to create a WSP Package in Build Definition

Visual Studio does not generate a WSP package by default for SharePoint projects. To do generate a WSP as part of your build definition, specify the /p:IsPackaging=True build parameter in the MSBuild Arguments.

Optionally, if you want to build a WSP package when you queue up a build, you can specify the build parameter at that time.

 

 

Gotchas and Considerations

Xavier Decoster (MyGet) was extremely helpful in making sure we got up an running.  The following are a items he listed as a checklist when setting up TFSBuild 2010 to use private MyGet feeds:

1. When using Enable Package Restore within Visual Studio, you have to make sure that the .nuget folder is checked into source control (including nuget.exe, nuget.targets and nuget.config).
2. By default, enable package restore only enables those projects that already consume NuGet packages. If you first enabled package restore and then started consuming packages, it is possible that some projects aren’t configured properly. You can verify this by checking whether the project files contain the <RestorePackages>true</RestorePackages> MSBuild property.
3. NuGet package restore assumes you have a solution in a root directory $(SolutionDir) and all projects have their own subdirectory (e.g. $(SolutionDir)\ProjectA\ProjectA.csproj). If you deviate from this convention, you have to manipulate the <SolutionDir> MSBuild element in the project files accordingly.
4. NuGet package restore requires a consent (due to privacy policy & legal requirements). This can be set using a system-wide environment variable, which is explained on the NuGet blog (http://blog.nuget.org/20120518/package-restore-and-consent.html)
5. Double-check whether your solution has the the actual nuget.exe commandline in the .nuget folder, and not the bootstrapper. The commandline is around 600Kb in file size, the bootstrapper 15Kb. The bootstrapper requires internet access, and has been made obsolete now. If you do not have this, it can be downloaded from http://nuget.org/api/v2/package/NuGet.CommandLine/2.0.0.
6. Ensure the nuget.targets file <PackageSources> element is pointing to the correct URL (in this case MyGet).
7. Ensure you checked in the Packages\repositories.config file (see my blog on how you can configure your workspace mapping accordingly). http://www.xavierdecoster.com/post/2011/10/17/Tell-TFS-not-to-add-NuGet-packages-to-source-control.aspx 
8. If you upgraded some regular references to NuGet package dependencies, ensure the <hintpath> in the project file for that reference is pointing towards the correct locatoin in the packages folder.
9. To verify package restore is fully functional on your local development machine, clear the $(SolutionDir)\Packages folder (except for the repositories.config file), clear all bin/obj folders, and clear the %LocalAppData%\NuGet\Cache folder. Then try building and see if all packages are restored correctly. Works on my local development machine.