Introduction
It has been a few articles I’ve been mentioning the fact that we (Negotium, the company I work for) have migrated to visual studio online (TFS Online). This service offers most of the features offered by the on premises version of Team Foundation Server 2013 and even some exclusive features.
If you have only a vague idea of what can do TFS2013/VSO and you want to learn more I very highly recommend Professional Application Lifecycle Management from Wrox.
The main parts of Visual Studio Online
TFS2013/VSO is divided in the strongly integrated with each other following parts:
- Work (understand plan): Allows you to schedule the work to be performed (agile or waterfall,…), track the progress, see the evolution of the delivery capacity…
- Code: Allows to centralize the code, follow the evolution of the code, everything that makes a great source control.
- Build: Generate compiled and versioned versions of code, tracked, with a changelog.
- Test: Ensures the quality of versions by running unit tests, deployments, functional tests automated or not.
How to set up everything?
Of course all these elements are related to each other which allows scenarios like “such automated test uses this portion of the code and has crashed, send reports and traces to the concerned developer and add elements to track the progress of the bug fix”.
When we begin to learn how this software factory works one realizes the need to implement things in a certain order. In July we migrated our existing code (ok not in order but it’s due to migration), immediately after that we reconsolidated our backlogs and reorganized the scrum teams. We were already using scrum in the past but following numerous movements of teams, the methodology was just not very well applied.
Automated build - benefits
The next step was the establishment of automated build with the following main objectives:
- Tracked, versioning and change notes of releases (already done but manually)
- Progress towards the implementation of automated tests
- Save Time
Choices you have with Visual Studio Online
You have two possibilities to perform automated builds with Visual Studio Online:
- Use the preconfigured online build service (hosted build)
- Setup your own machine and connect it to the service
The obvious advantage of hosted build service is not having to spend time in configuration of the environment and paying only for the build time that you use and not for the rest of the time where the machine would be unused.
According to this page https://www.VisualStudio.com/en-us/get-started/hosted-build-controller-vs.aspx#software SharePoint 2010 and 2013 (as well as many other components) are installed on the hosted build environments provided by Visual Studio Online. So I naturally started to configure my build plan using this service.
However what is not clear it is that installed SharePoint edition is Foundation. My project being based on some of the dll’s of the Server edition (publication, translation…) two choices were available to me:
- Including a local copy of the missing dll’s in my source code control
- Set up my build machine
It is obvious that including the missing dll’s will clearly increase the weight of source code, may cause conflicts and will require updating them regularly. I therefore chose the second option.
Configure build machine for SharePoint Server 2013 (full trust)
The build machine setup steps are not so complicated that what I had to do:
- Install SharePoint server 2013 (only the binary, not psconfig to pass)
- Install Visual Studio 2013
- Install the Office dev tools (from web platform installer)
- Install the TFS build agent and controller, then connect it to my visual studio online (https://msdn.microsoft.com/en-US/library/ms181712#deploy ) )
First error: version MSBuild is using
Once finished I had the privilege to get this beautiful error message: cannot find build process template for project type SharePoint…
This is due to the fact that for some reason, MSBuild framework (this is the technology that runs the build process) believes that it has to use version 11 (2012) of Visual studio. This does not match the installed versions of visual studio and Office development tools.
To fix this problem simply edit build definition, on the process tab, click on advanced, and then specify /p:VisualStudioVersion=12.0 for MS Build Arguments.
Second error: Version of the SharePoint tooling
Once this is done, you’ll get another error, which is mainly related to the same problem: with the new version of workflows, process templates of traditional workflows have been moved but the references were not updated. I am also surprised that 2 years after the first releases of the tools, this still hasn’t been fixed.
Start by making a backup of the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SharePointTools\Microsoft.VisualStudio.SharePoint.Workflow.targets and then edit it.
Replace lines 37 and 38
<Import Condition="'$(Language)' == 'C#'" Project="$(MSBuildFrameworkToolsPath)\Workflow.Targets" />
<Import Condition="'$(Language)' == 'VB'" Project="$(MSBuildFrameworkToolsPath)\Workflow.VisualBasic.targets" />
By
<Import Condition="'$(Language)' == 'C#'" Project="$(MSBuildFrameworkToolsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets" />
<Import Condition="'$(Language)' == 'VB'" Project="$(MSBuildFrameworkToolsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.targets" />
Conclusion
Et voila! Now automated builds of SharePoint Server 2013 full trust projects are set up. Note that this works for Team Foundation Server 2013 as well as for Visual Studio Online. Also, my build machine is hosted on Azure but it could be on prem too.
Next time I’ll probably be writing about assemblies version numbers increment and/or pre/post build scripts since these are the two elements that I’m me before being able to implement automated test.