This week I was faced with a scenario where a TFS build/release agent was used to deploy software from TFS Release management. This agent was running in the same Windows domain as the servers where the software needed to be deployed. The TFS server itself was running in a different Windows domain. Because of security considerations (these are production servers we’re talking about), these two Windows domain did not have a domain trust configured between them.
Last week I introduced a client to the new TFS 2015 build system. They happily started experimenting with it, but soon ran into a bit of a cryptic error message saying “Unable to load task handler … for task …”.
In the past few weeks I’ve been playing around with containerizing an ASP.NET Core application using the Docker tools for Visual Studio. This allows you to develop and debug your app locally inside a Docker container. To do this, you’ll need a local Docker host. While you could ask your IT department to provide one for you, I found it much more convenient to run a virtual machine locally on my laptop, so I have it available everywhere I go. To create a local Docker host, you need to use the Docker Toolbox. This will use VirtualBox to create a local virtual machine which will serve as your Docker host. However, I already had Hyper-V installed as a virtualization hypervisor. Hyper-V works great on Windows 10, so I wanted to keep that. Sadly, VirtualBox doesn’t play nice with Hyper-V (in short, VirtualBox won’t install if Hyper-V is enabled).
Recently I’ve been working on developing some extensions for Visual Studio Team Services (VSTS). Being able to develop custom extensions is great, since it enables you to extend the service with features that fulfil your needs.
Creating an extension for VSTS consists of a few steps:
- Develop the code
- Package the extension
- Publish it to the marketplace
- Install it in your VSTS account
- Start using your extension!
The new build system which was introduced in Visual Studio Team Services (VSTS) and TFS 2015 has been gaining more popularity lately, and (in my opinion) rightly so. It simply works far better than the old XAML builds. I’ve been converting quite a few XAML based builds to the new build system. While doing this, I (inevitably of course) came across quite a few custom build workflows and tasks. Some of these were easily converted to build tasks that are available out-of-the-box, while others required some custom tasks. When creating a custom build or a custom build task, you’ll at some point need some build-specific information. This is where environment variables become necessary. Since I wasn’t too familiar with the concept (I’d heard of them, but never really used them) I decided to dig a little deeper.
[Update 2015-08-12] Microsoft has just made a new command-line utility called “tfx-cli” available which allows you to create, upload, delete and list build tasks. You can use that, instead of the “TaskUploader” described in this post. I’ll leave this post up here, since the part about building the tasks is still useful.
“tfx-cli” is distributed through npm and can be found here.
A nice walkthrough by Jeff Bramwell can be found on his blog here.
OK, one more post for today… This morning I promised you I would show you how to build Java code on a Linux build agent using the new Build.vNext build system in Visual Studio Online. This post is to deliver on that promise. Being a Linux and a Java newbie, I thought it would be a complex task. As it turns out, it isn’t. Once you have all the bits in place, the great new build system makes it easy to create a build definition that compiles the code. Actually, I even stuck some unit tests in there and got the test results to publish to VSO.