While exploring features of the new Visual Studio Team Foundation Server 2015 I found that it is not possible to reuse a build definition created in one team project into another team project. Since this is a feature that I am going to use frequently, well, every time I start a new project, this is a must have functionality. In this post I will give you a complete solution I’ve came up with.
If you’ve been following Microsoft announcements about Visual Studio Online over the last 12 months, you already know that you can easili integrate with VSO from any platform, technology, or device. Everything thanks to a new set of of JSON-based REST APIs. Those APIs enable a lightweight way to work with Team Foundation Server from virtually any device, platform, or technology…
I’ve used a few version control systems: visual source safe, subversion, git, mercurial and tfs. My current favourite – git. It it’s the most popular one at the moment, but to be honest there’s a good reason for that. It has a gigantic learning curve, but once you grok the concept, everything falls into place. My second choice – subversion. I’ve used it for a long time and it got the job done. The one I am using at the moment – tfs and here’s where the story starts.
Signing is a bit more tricky than strong naming. I didn’t want to use delay signing, because that requires additional configuration on development stations, so just like with strong naming – plain old simple build on the development machine and the fancy stuff on the build server.
Today we’re going to look at another build script adjustment – strong naming assemblies.
The scenario we are aiming for is that during development, the assemblies are not signed (so developers don’t need to have the a certificate file - a little bit more on that later), but during a build on the build server they are. This can be handled by providing additional parameters to msbuild.