This video on YouTube shows off a new UI called Pointui for Windows Mobile. Very cool, I hope the Windows Mobile team is taking notes, the WM user community is ready of a UI upgrade, and I don’t just mean putting gradients on the background of the existing UI.
One interesting thing that I noted was the carrier being used in the demo. Looks like this might be an Australian invention.
Thanks to Jason Langridge for pointing this out on his blog.
Correction: You may carry the batteries on as carry on luggage, but not as checked luggage. The text has been corrected below.
I just stumbled upon this article on Slashdot that points out some new rules from the TSA (I’m an Australian living in Australia so it doesn’t impact me until I travel into the US) about how many lithium batteries that you can take on a plane as hand checked luggage.
There seems to be some confusion about what capacity/weight ratio the restriction kicks in at and there is some mild outrage from what a probably geeks carrying large amounts of devices (I count myself in that number). That said, I doubt that the new rule is that onerous except where it is executed by individuals with insufficient training.
Last year I posted about the impact of the Dell/Apple/other battery recall on the travelling public - well, at least how it impacted me 
I just put together a quick little example of how to host PowerShell inside your own application, but to make it more useful I built it as an extension method so that you can basically call ToPowerShell(…) on any object. If the object happens to implement IEnumerable then there is an alternative ToPowerShell(…) which allows you to specify whether to enumerate the items.
Download the sample if you are interested.
Today I finished publishing a number of tools under the MIT license to CodePlex. Two of these tools represent a replacement for a single tool that Readify released last year called TFS Integrator. If you are currently using TFS Integrator I strongly recommend that you adopt “TFS Continuous Integrator” and “TFS Dependency Replicator“.
TFS Integrator originally included two features, support for continuous integration, and support for dependency replication. Now that Team Foundation Server 2008 is released the continuous integration functionality of TFS Integrator is now redundant so we decided to split the functionality out into two separate tools.
Moving forward TFS Continuous Integrator will just contain the continuous integration functionality for customers who are still running Team Foundation Server 2005, however TFS Dependency Replicator will be updated to support Team Foundation Server 2008 (it already supports Team Foundation Server 2005).
By open sourcing the tools under the MIT license we hope to address any concerns our customers have about the maintenance of the software moving forward (because they can get the code and maintain it themselvesm if necessary).
Note that some customers reported that TFS Integrator had some stability problems. We are confident that these two new releases address those concerns. We drastically simplified the implementation (less code = less complexity = less bugs), but also changed it so that rather than relying on the TFS evening system, we actually poll the repository which leads to less comms related issues.
Finally, in addition to releasing TFS Continuous Integrator and TFS Dependency Replicator we have also released TFS Build Virtualizer and TFS File Sharer.
I’ve been throwing a few tools out under the MIT license over the last week or so, and the final one to make it out the door is a continuous integration engine for Team Foundation Server 2005. Now that Team Foundation Server 2008 has shipped this is less useful, but I wanted to put it out there anyway as a replacement for TFS Integrator which we shipped last year. Here is the description of TFS Continuous Integrator from the CodePlex homepage:
“TFS Continuous Integrator extends Team Foundation Server 2005 to support continuous integration by triggering a build when a check-in occurs at a specific location.
The tool works by monitoring the version control store for changes, then once identified pulling down configuration files contained within the store to determine which builds should be initiated.”
Setting up TFS Continuous Integrator is very straight forward.
Installing and Configuring the Continuous Integrator Component
In order to install the Continuous Integrator component you need to first download the release from CodePlex. From this zip file you need to extract the following files:
These two files should be placed somewhere on the file system of your TFS server. I would recommend “C:\Program Files\Continuous Integrator”. Once these files are in place you should issue the following command at the command prompt:
During the installation process a dialog will be presented asking for some credentials. I recommend using the build service account (e.g. [DOMAIN]\TFSBUILD) because it generally has the rights needed to talk to the build engine in TFS and trawl the version control respository for changeset information. The configuration file for TFS Continuous Integrator also needs to be updated:
Now that the base-line configuration is in place its time to start up the service:
Before any CI builds start kicking off some per-Team Project configuration needs to be added in via version control. These files are checked in under the TeamBuildTypes folder under each Team Project (e.g. $/ConsultantPortal/TeamBuildTypes/ContinuousIntegrator.xml).
TFS Continuous Integrator will then pull down this file each time a check-in occurs to determine whether it needs to trigger a build.
What’s next? Want to help out?
If you have any feedback please use the Issue Tracker and create a work item. Because Team Foundation Server 2008 has superior continuous integration features out of the box I don’t expect this project to get too much love.
If you are interested in helping out contact me via my CodePlex profile page. Thanks for listening! I hope you find the TFS Continuous Integrator useful in your organisation.
P.S. Please note that once we get real documentation in the CodePlex wiki this page will become obsolete, but I will put a link to the equivalent documentation at the top of the page.
We just released another internal tool under the MIT license, this time it is an extension for Team Foundation Server 2005 (2008 version will ship soon) that helps organisations mimic the file linking capability of repositories like Visual SourceSafe.
In the field I’ve seen a lot of customers struggling with adopting TFS because the configuration of their VSS repositories rely heavily on the ability to get file linking happening to update common source files. TFS File Sharer should hopefully help customers side step this problem, here is the description from the project homepage on CodePlex:
“The TFS File Sharer is a tool designed to assist development teams who have migrated from version control stores that support the concept of linked files where one file update automatically updates all the other linked files - for example VSS.
The TFS File Sharer reads a configuration file that lists out all of the shared files within an environment and then when it notices a check-in that changes one of those shared files it updates all the other files that have explicitly been listed as being linked to it.
Using this tool will allow users migrating from other source systems to more easily adopt Team Foundation Version Control and then slowly phase out the use of file linking.”
Now lets look at what it takes to get it running in your environment.
Installing and Configuring the File Sharer
In order to install the File Sharer component you need to first download the release from CodePlex. From this zip file you need to extract the following files:
These three files should be placed somewhere on the file system of your TFS server. I would recommend “C:\Program Files\File Sharer”. Once these files are in place you should issue the following command at the command prompt:
During the installation process a dialog will be displayed asking for valid windows credentials. This needs to be an account that has check-out/check-in rights to all the files that are going to be shared using this tool. The configuration file, FileSharer.xml lists out all of the files.
The files are organised into sets with names, and each set has multiple file references. If one of the files referenced is updated, then all the files referenced will be overwritten with that copy of the file. The tool has some de-duping logic built into it so if that two files are changed from the same set, it will pick a winner but because independent versions are checked in before being overwritten you shouldn’t loose any data.
Finally, once you have it all configured you can start the service using the following command:
Once it is running you should see follow-up check in notifications when you check-in a shared file as it is updating the other shared files. Just remember that it doesn’t force the updates down into other users workspaces.
What’s next? Want to help out?
If you have any feedback please use the Issue Tracker and create a work item. Finally if you would like to help out with the project I’ve got the following roles available:
If you are interested contact me via my CodePlex profile page. Thanks for listening! I hope you find the TFS File Sharer useful in your organisation.
P.S. Please note that once we get real documentation in the CodePlex wiki this page will become obsolete, but I will put a link to the equivalent documentation at the top of the page.
I’m in a bit of a prickly mood right now. Its been a long month with lots of unexpected work, expected (yet strangely not catered for) interruptions. I’ve got deadlines to meet and family commitments. Others working with me are in the same situation or worse - so I can’t blame them.
What I don’t appreciate however is those who could be a little bit flexible not lending a hand to ease the burden a little bit, but instead finding it more fun (for them) to make me feel extra bad (thus increasing my stress levels further) when I slip a little. And I better not dare ask for help.
Fortunately I believe in Karma. So should some other people.
</rant>
Following the success of the DasKeyboard a new keyboard has just hit the market designed exclusively for the special needs of system administrators. Announcing the Sysop Keyboard!
The keyboard design came from years of research working with gorillas and other (direct) ancestors of the modern system administrator. The key arrangement allows the system administrator to reboot the server by rapidly bashing a clenched fist on the keyboard.
The keyboard isn’t expected to ship until Q2 2008, however you can pre-order now on Amazon. Following shortly after this release will be a purpose built Slashdot keyboard with special “Insightful”, “Funny” and “Me too!” buttons.
Continuing with the theme of releasing some of our internal tools as open source I have just uploaded the source and created a release on CodePlex for another tool that we have been using for a while called TFS Dependency Replicator. The project description up on CodePlex is as follows:
“The TFS Dependency Replicator is a tool that monitors the Team Foundation Server Build Store for the successful completion of new builds, or the change in qualify status of existing builds. When a change is detected TFS Dependency Replicator looks up a configuration file in the version control store and determines if any files from the build drop location need to be copied back into the source tree.
TFS Dependency Replicator is useful for complex build scenarios where a common framework is used across a range of products and once a new build of that framework is completed it needs to be published back into the source tree in binary for so other code bases automatically start using it.
This tool saves development teams the tedious task of manually updating binary dependencies produced from upstream builds.”
Once again, as with the TFS Build Virtualizer, if you would like to get involved with this project please contact me via my CodePlex profile page.
Installing and Configuring the Dependency Replicator Component
in order to install the Dependency Replicator component you need to first download the release from CodePlex. From this zip file you need to extract the following files:
These two files should be placed somewhere on the file system of your TFS server. I would recommend “C:\Program Files\Dependency Replicator”. Once these files are in place you should issue the following command at the command prompt:
During the installation process a dialog will be displayed asking for valid windows credentials. Typically I woul use the build service account (e.g. [DOMAIN]\TFSBUILD) for this purpose. Once this is configured you need to modify the configuration file, DependencyReplicator.exe.config, the contents of the file are as follows.
You need to update both the name of the TFS server, and optionally the location in which the TFS Dependency Replicator will perform source control operations. This configuration shows that the dependency replicator is configured to poll the TFS build store every five seconds, you may want to revise that upwards a little bit in your environment depending on how stressed your TFS server is.
Once this configuration is complete, TFS Dependency Replicator is ready to be switched on. Issue the following command at the command prompt.
Once the dependency replicator is running you then need to put configuration files into the source code repository to control what files will be replicated from successful builds.
Configuring Your Builds for Dependency Replication
Dependency replication configuration files are stored under each Team Project in a well known location so that the tool can find it and process them when the build store is updated. The file is called “DependencyReplicator.xml” and is located under each projects TeamBuildTypes folder, for example “$/HelloWorld/TeamBuildTypes/DependencyReplicator.xml”. The following sample file shows the configuration required to have a single file be replicated from the drop folder relative path (Source) to the absolute location in version control (Destination).
Another way of configuring the dependency replicator is to not have it replicate after each successful build, but rather to have it replicate only after a specific build quality has been reached and flagged in the build store. The configuration below shows how to listen for the QualityChanged events, and the BuildQuality attribute specifies which quality level the replication activity is triggered on.
What’s next? Want to help out?
If you have any feedback please use the Issue Tracker and create a work item. Finally if you would like to help out with the project I’ve got the following roles available:
If you are interested contact me via my CodePlex profile page. Thanks for listening! I hope you find the TFS Dependency Replicator useful in your organisation.
P.S. Please note that once we get real documentation in the CodePlex wiki this page will become obsolete, but I will put a link to the equivalent documentation at the top of the page.
Today I uploaded the source for TFS Build Virtualizer to CodePlex under the MIT license. I have also put up a release (1.0 RTM) which is compatible with Team Foundation Server 2005 and Virtual Server 2005 R2 SP1. The TFS Build Virtualizer was originally developed by Readify.
From the project description:
“TFS Build Virtualizer is an extension to the Team Foundation Server build system which allows build masters to have a large number of virtualized build servers with Team Build installed. When a build is invoked the build virtualizer determines which build server to use to run the build and communicates with Virtual Server 2005 where it exists in a saved state.
The build virtualizer resumes the build server from saved state, and forwards the build request into the build server where it builds normally. Once the build completes (success or failure) the build server is put into a saved state once again.
Benefits of using this approach include being able to have a large number of build servers (for each team, or different build environment) and be limited by only the amount of available disk space.
The build virtualizer is designed to accommodation multiple different TFS servers and has configuration settings to restrict which hosted virtual machines developers can request access to.”
If you would like to get involved with this project please contact me via my CodePlex profile page, or, if you find any problems or requests create a work item via the Issue Tracker.
Getting Started with TFS Build Virtualizer
TFS Build Virtualizer is installed as two components. A component that is installed on the Team Foundation Server, and a component that is installed on Virtual Server 2005. These components are called “Build Virtualizer” and “Build Virtualizer Proxy” respectively.
The Build Virtualizer is responsible for mocking a Team Build instance and forwards requests to the Build Virtualizer Proxy to start up virtual machines over a WCF channel. The Build Virtualizer Proxy communicates with Virtual Server 2005 R2 SP1 via the COM automation API.
Installing and Configuring the Build Virtualizer Component
In order to install the Build Virtualizer component you need to first download the release from CodePlex. From this zip file you need to extract the following files:
These two files should be placed somewhere in the file system of your TFS server. I would recommend “C:\Program Files\Build Virtualizer”. Once these files are in place you should issue the following command at the command prompt:
During the installation/configuration process a dialog will be displayed asking for valid windows credentials. Typically I would use the build service account (e.g. [DOMAIN]\TFSBUILD) for this purpose. Once this is configured you need to modify the configuration file, BuildVirtualizer.exe.config, the contents of the file are as follows.
First, change the endpoint that Build Virtualizer will communicate to the Build Virtualizer Proxy with. This is typically done by replacing “localhost” with the name of the Virtual Server 2005 R2 SP1 machine.
Next, specify the name of the Team Foundation Server that the Build Virtualizer will communicate with to initiate builds. You might also like to specify a “DefaultBuildMachine” to use if a build type has not been explicitly configured to use the virtualization features.
Finally, specify the names of the build servers (running as virtual machines) that the Build Virtualizer instance on this machine will be allowed to request that the Build Virtualizer Proxy starts.
Finally, in the Team Project’s build type directory needs to have a BuildVirtualizer.xml file added (sample location: $/MyProject/TeamBuildTypes/BuildVirtualizer.xml). The Build Virtualizer reads this file whenever a build is initiated:
If a mapping is missing for a particular build type, then the default build server is used. All the build types that use virtualization should then be configured to point to the local TFS server as the Team Build server (Team Build should be stopped/disabled on the TFS server). Once this configuration is done it is safe to start the Build Virtualizer on the TFS server with the following command:
Next up, we need to configure the Build Virtualizer Proxy on the Virtual Server 2005 R2 SP1 machine.
Installing and Configuring the Build Virtualizer Proxy Component
In order to install the Build Virtualizer Proxy component you need to first download the release from CodePlex. From this zip file you need to extract the following files:
These two files should be placed somewhere in the file system of your TFS server. I would recommend “C:\Program Files\Build Virtualizer”. Once these files are in place you should issue the following command at the command prompt:
During the installation/configuration process a dialog will be displayed asking for valid windows credentials. Typically I would use the build service account (e.g. [DOMAIN]\TFSBUILD) for this purpose. Once this is configured you need to modify the configuration file, BuildVirtualizerProxy.exe.config, the contents of the file are as follows.
The service endpoint address needs to be configured so that the Build Virtualizer messages are processed correctly, this should be the name that the Build Virtualizer knows the server by.
Optionally, the metadata GET URL should be updated with the host name as well:
And finally, the list of build servers that the Build Virtualizer Proxy is allowed to start and stop in Virtual Server need to be specified. The idea is that the Build Virtualizer Proxy can actually service multiple Team Foundation Server instances, but this list is the governing superset of build servers that can be worked with. The similar list in the BuildVirtualizer.exe.config file is the build servers that the users of that TFS instance can get access to. It isn’t designed to be a security mechanism, just a sanity filter.
Finally, once you have configured the Build Virtualizer Proxy, you need to start it with the following command:
Now to get your build servers up and running.
Preparing Your Virtual Build Servers
Once you have configured the Build Virtualizer and Build Virtualizer Proxy, you need to create a virtualized build server that they can start and stop. You may have some of these already. Once they are configured with Team Build and connected to the Team Foundation Server instance, simply go to the Virtual Server 2005 R2 SP1 console and “save state” the virtual machine. Once you initiate a build the build virtualizer should intercept it, start the build server, perform the build, and then save its state back down to disk.
What’s next? Want to help out?
If you have any feedback please use the Issue Tracker and create a work item. Finally if you would like to help out with the project I’ve got the following roles available:
If you are interested contact me via my CodePlex profile page. Thanks for listening! I hope you find the TFS Build Virtualizer useful in your organisation.
P.S. Please note that once we get real documentation in the CodePlex wiki this page will become obsolete, but I will put a link to the equivalent documentation at the top of the page.
Twitter
|
Recent Comments