I have a 16GB laptop which when running Windows 8 I was able to start some 10GB+ virtual machines for doing SharePoint development on. However since upgrading to Windows 8.1 I have been unable to start up these virtual machines.
The cause is in the more aggressive way that Windows 8.1 reserves memory for itself and fortunately Microsoft have some registry settings we can tweak to change this. For information on these keys refer to http://support.microsoft.com/kb/2911380. If you want to avoid restarting you machine at least restart the “Hyper-V Virtual Machine Management” service, and schedule a restart for the first convenient opportunity.
I looked at the blog the other day and realised that I hadn’t posted in quite some time so l thought it would be time l did an update. But looking back over the last few months all see is lots of work. There has been lots of it and some of it probably deserves a blog post or two. The problem is that there don’t appear to be any slowdown in the lead up to Christmas for the third year in a row. So what has happened?
- We moved house
- Done work for about 5 different customers
- Attended funeral of my Grandmother
- Family holiday in Australia
- Attended funeral of a good friend
- Built a SharePoint as service platform for Datacom.
- Got my vTSP credentials for SharePoint
So pretty much I’ve just been doing life. Hang on did I hear you ask what a vTSP was? Well that is a good question. While the rest of the list was happening, Microsoft was slowly turning the wheels to induct me into this elite team of specialists, chosen from amongst the partner community. The purpose of the vTSP is to help their regional sales teams by providing in depth technical support and knowledge, in return they receive access to a large amount of Microsoft internal resources.
Hopefully I’ll get a bit more time on the next little while to put some more blog posts up. I’m planning on providing an update to my continuous integration with SharePoint series to bring it up to Vs2013/SP2013 and TFS online. As well as some other articles on claims and AD FS with SharePoint.
Until next time.
This year I presented at the New Zealand SharePoint conference how to build and deploy SharePoint solutions automatically with TFS. Here is the presentation.
I just thought I’d confirm here that I’ll be speaking at the New Zealand SharePoint Conference this year in April, make sure you grab your tickets now.
So awhile ago I mentioned automated versioning of components during a TFS Build. At the time I suggested Chris O’Brien’s approach, which is a good simple approach. However, if you want something a bit more powerful take a look at TSVersioning.
TFSVersioning is a codeplex project that has heaps of versioning goodness and good documentation to match.
It is really easy to add to build process just following the instructions they have given.
When using this with SharePoint projects the only limitation I found was that you needed to apply the Assembly Version Pattern which obviously you don’t want to do with SharePoint. This appears to be a limitation in one of the embedded XAML files.
If you want to remove this limitation then just do the following. Download the source code (I’m using the 184.108.40.206 version.) and open the solution in Visual Studio.
Find the VersionAssemblyInfoFiles.xaml file and open up the designer.
Find the node that task that says “Validate then process Build Definition Values”. Chagne the “Or” in the condition to an “And” so it reads “String.IsNullOrWhiteSpace(AssemblyVersionPattern) And String.IsNullOrWhiteSpace(AssemblyFileVersionPattern)”.
Compile the project and use the DLL instead of the one included in the package.
The other XAML and flows already allow you to specify either the AssemblyFileVersionPattern or AssemblyVersionPattern, just not this flow.
Note: Version 2 has been released for TFS2012, I do not know if that version has this limitation or not.
This is the fourth, and probably final, in a multipart post about automating the build and deployment of SharePoint solutions. The other blog posts are:
In this post we will put all these bits together to form one process from check-in to deployed solution. Again as in the rest of this series this post is going focus on the principles behind this task, and how we went about it. It is not going to give any code.
So far we have built an automatic deployment script, got automated builds happening that build the package for deployment. Now we need to get the automated build triggering a deployment into a staging or test environment.
We could use the lab management features of TFS Team Build to handle this, and that would be good way of going. But the approach we decided to use was chosen as the only dependant tool is PowerShell, the other active components can be replaced with anything that will do that task, which there are a few to choose from.
For our team, in order to leverage the work that had been done by other teams just before us we decided to use TFS Deployer to launch the deployment based on changes to the build quality.
In order to allow TFS Deployer to do its job we need to enable PowerShell remoting from the build server (as the client) and our target SharePoint server (as the server).
To setup the SharePoint server open an elevated PowerShell prompt and enter the following commands:
Enable-PSRemoting -force Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000 Enable-WSManCredSSP -Role Server
This script enables remoting, increases the size of the memory available and then allows the server to delegate authentication to another server. This enables our deployment script to issue commands on other parts of the farm if required.
The build server is our client so there is a little more work to do from the client.
# Enable Powershell remoting on server $SharePointServer = "SharePointServer" Enable-PSRemoting -force Set-Item -force WSMan:\localhost\Client\TrustedHosts $SharePointServer Restart-Service winrm # Enable client to delegate credentials to the a server Enable-WSManCredSSP –Role Client –DelegateComputer $SharePointServer #Also need to edit Group Policy to enable Credential Delegation
Further information on this entire process can be found at Keith Hill’s blog http://rkeithhill.wordpress.com/2009/05/02/powershell-v2-remoting-on-workgroup-joined-computers-%E2%80%93-yes-it-can-be-done/.
TFS Deployer – The agent in the middle
TFS Deployer is the tool we have chosen, it is not the only one, to detect the change in the Build Quality and launch the scripted deployment on the chosen environment.
TFS Deployer had got a good set of instructions on their project site. To simply our environments we run TFS Deployer on the build server.
In order to simplify the process for our many clients and projects we have TFS Deployer call a generic script that first copies the project specific deployment, after interrogating the $TfsDeployerBuildDetail object for the location of the files. It then calls that deployment script to execute the deployment.
The project specific script file is also reasonably generic. It first copies the packaged output (see previous posts) to the target server. It then remotely extracts the files and executes the deployment scripts from inside that package. Of course, in this scenario we know all the parameters that need to be passed so we can conveniently bypass any prompting by supplying all the parameters needed.
That ends the series. Unfortunately it has been code light, as I was working through the process and trying to capture the philosophies rather than the actual mechanism. Hopefully you have learnt something from reading these posts and picked up a few tips along the way.
As stated in the first post the purpose of this series was to put together and understand our build framework and requirements so that I could build a new version using the TFS Build workflow mechanism. I believe I now have that understanding, so I can start that work. Perhaps doing that work will lead to a few more blog posts in the future.
This is the third in a multipart post about automating the build and deployment of SharePoint solutions. The other blog posts are:
In this post we will look at the build itself. Again as in the rest of this series this post is going focus on the principles behind this task, and how we went about it. It is not going to give any code.
If we are doing SharePoint solutions, surely a quick build from the Visual Studio environment, and a package from there, will produce the correct output for us. Why should we go through the pain of automating the build process?
That is a very good question. Here are a few reasons:
- Ensure that the code can be built consistently from any development machine
- Ensure that everything required for the build are in the source control repository.
- Ensure that what is in source control builds.
- Ensure regular testing of the build process.
- Ensure rapid resolution of a broken build.
But of course it comes back to down to the big three we mentioned in a previous post: Simplify, Repeatable and Reliable.
Simplify – Because in this case we are simplifying the work we need to do, and the associated documentation required.
Repeatable – Because we need to be able to repeat the process. Maybe the build won’t be built again for a year, but we need to ensure that when that time comes we can do it.
Reliable – Because as long as it builds the output is known to be built the same way, and in the same order.
But the most important reason of all. It is not hard to set up.
The build process only needs to do one thing. Change the source code to the deployment package we talked about in the previous post.
One of the advantages of automating everything is that we can ensure that all parts in the process are tagged and labelled so that we can find the exact code that was used to generate the components running in production.
In order to do that we are going to need the following actions performed:
- Automatic increment of a version number.
- Labelling the source code with the above version number.
- Stamping of all components with the build name, and version number.
- Build of the source code
- Package the built binaries into WSP packages, for SharePoint.
- Package of the WSPs, and our Deployment scripts into the package.
That seems like a lot, but as you will see most of that can be performed by the Team Foundation Build services.
How? – Building the solution
Team Foundation Server (and the service offering) make this a really easy task. From Team Explorer just expand the build node, right click, select “create a new build definition…” and follow the wizard.
There are a few extra things that you will need to do to build SharePoint projects though:
- SharePoint assemblies need to be on the build agent. Chris O’Brien has this covered in his post Creating your first TFS Build Process for SharePoint projects. While not recommend to install SharePoint on the build server, we have installed the binaries on the server but NOT configured it as a farm, which would kill the performance of the server. We also install Visual Studio, but this again is not necessary or advisable. I suggest that you follow the How to Build SharePoint Projects with TFS Team Build on MSDN as that provides good alternatives and clearly lays out the process.
- /p:IsPackaging=True needs to be added to the MSBuild arguments parameter so that TFS will tell MSBuild to also perform the SharePoint packaging tasks and create the WSPs.
How? – Versioning
Every .Net assembly contains two version numbers: the assembly version, which is used in the strong name and thus needs to be bound into a lot of the element.xml files. And the file version number, which is just that a number.
Therefore for our purposes the file version number is adequate, not to mention less complex to implement, to track the running components back to the source code.
We will also need to use the version number as part, or all, of the build number and ensure that the source code repository is labelled with the build number as well. Fortunately TFS Build already performs these actions for us.
Chris O’Brien has a simple workflow extension, and instructions, based on another derivative work. For further information and for how to extend the TFS build template to include this versioning see part 6 of his continuous integration series.
How? – Packaging
Once the build has done the work of building the assemblies and the SharePoint packages the next step is to package these artefacts into the deployment package we mentioned in the previous post.
The team I was part of did this in the old TFS 2005 format (which used MSBuild) by extending the PackageBinaries target. In addition we were able to separate the definition of the package from the creation of the package by using MSBuild include files. This has made the solution developed incredibly easy to implement and highly reusable even though it is in the MSBuild format.
To integrate this with the newer TFS build workflows we just need to modify the build workflow to call this target at the appropriate place, after the components have been built.
The process for packaging is really quite simple:
1. Build the package in a staging directory structure by copying the output files from the appropriate place.
2. Zip up the staging directory.
3. Ensure that the zip file is included as a build output.
So now we have talked about the overall strategy, the deployment package and how we create the deployment package. In the next post we will tie all the parts together to show how we can get all the way from the code to the running SharePoint server, every, or almost every, time that someone checks in some code.