After several hours of pain trying to update the build displayName from the GitVersion output I came up with this:
stage 'Run GitVersion'
bat 'git remote remove origin1' // For some reason the pipeline is adding duplicate remotes that GitVersion moans about
currentBuild.displayName = (bat (script: '@echo off && GitVersion.exe /showvariable FullSemVer', returnStdout: true))
Let me know if you think there is a better way! 🙂
Whilst working on a personal project using the excellent betfair-ng gem that I converted to a ruby on rails project I came across a strange issue Once When running the code I was getting the following error.
uninitialized constant Betfair::Client
It took a while to realise that this was caused by the autoloading feature of rails. However working out what to do to fix it turned out to be a little tricky but actually very simple. All I needed to do was to to move the `require` into the class initializer:
@client = Betfair::Client('X-Application', app_key)
I’m still quite new to ruby so don’t really know the full impact of this change, but it seems to work fine so far.
So it turns out that I didn’t need to do that way. I just needed to change the line in the Gemfile from
gem 'betfair-ng', require: 'betfair'
This then meant that I could remove the require from the class completely and rails now hooks it up.
Today I had an issue with a wix based msi that I was developing. The msi was installing and starting up a TopShelf based service. However I forgot to add a condition to stop it trying to start the service when it was being removed and this was failing as the exe had been removed by the time it tried to start the service, doh!
This was a big problem as by default I do major upgrades that un-installs the old version before installing the new one.
With a little digging on the wix forums I managed to work it out. Basically you have to replace the msi that is cached in the C:\Windows\Installer folder with the new one that fixes the issue. To do this you need to make sure that the ProductId is the same and run the following msiexec command:
msiexec /fv [PathToYourInstaller]
This replaces the cached one with your fixed one which you will be able to uninstall.
If you don’t know the ProductId as you get wix to auto-generate it using ProductId=’*’ like I do, you will have to find the cached installer in the C:\Windows\Installer directory (I ordered by size and then found it by comparing the size). Then use InstaEdIt! or Orca to open up the msi and find the ProductId in the Properties table. Temporarily use this in the wix code create a new msi.
The other day I came across a bit of a strange issue when trying to delploy a backup to a fresh SqlExpress 2008 R2 instance. I had setup the Wix Sql database tag using a loopback address:
but for some reason it wasn’t connecting at all just erroring with a most helpful error message:
CreateDatabase: Error 0x80004005: failed to create SQL database but continuing, error: unknown error, Database: [DATABASE_NAME]
I enabled TCP/IP so that I could use sql profiler and re-ran the installer hey presto guess what it worked! Obviously as SqlExpress only installs with “Shared memory” enabled this was the issue, it couldn’t connect. I tried the sqlcmd method of using “lpc:” as a prefix but still no joy. It turns out that if you cannot use a hostname or ip for the servername to switch over to shared memory’ you have to use “.” as the server name:
Recently I have been back creating Wix installers and unfortunately I came across a a bug in the RC0 that was causing issues with my Burn bootstrapper. This had already been fixed in the latest sources so I went ahead and built the latest sources. This wasn’t as easy as I though it would be so here are the steps I needed to take:
- Install the Windows SDK 7.1 (http://www.microsoft.com/en-us/download/details.aspx?id=8279) (I just did a full install)
- Install Mercurial (http://mercurial.selenic.com/)
- Clone the latest Wix sources into a local folder (hg clone https://hg.codeplex.com/wix)
- Change directory to the new wix folder.
- Switch to the Wix36 branch (hg update wix36).
- Setup an environment variable called WIX_ROOT pointing to your newly downloaded sources (In my case C:\source\codeplex\wix).
- Open up a VS2010 command prompt in administrator mode and navigate to the WIX_ROOT path.
- Run make.bat.
Now once that is completed, hopefully you should only have non-fatal errors and warnings an if that is the case the latest wix installer will be located under %WIX_ROOT%\build\debug\x86\release\%WIX_VERSION%\.
This really bit me in the arse today and wasted about 2 hours of my time so I thought I’d better blog about it!
I was splitting out the Properties required for a WixProject today and could not work out why the changes to my imported proj file were not being imported.
It turns out that VS2010 is really helpful when it comes to this and will cache the properties the first time they are loaded. Unfortunately it looks like the only way to get around this “feature” is to restart visual studio or use the msbuild commandline to build your project.
A while back I was setting up TFS Lab management so that we can start automating a lot of our integration testing. In the process of testing the deployment of the servers and the auto configuration scripts I was creating a lot of temporary virtual servers on the domain and using up IP’s on the network before they could be released. Therefore I wasn’t too popular with the OP’s guys and they decided to put the lab server in it’s own domain.
Unfortunately this caused a few issues as it meant that the SCVMM backed could not contact the hosts and the library servers as they had moved domain. Removing the hosts was a simple matter of dropping to PowerShell (There is a handy button at the top of the SCVMM Admin console) and running the following command:
Remove-VMHost "[SERVER_FQDN]" -Force
However the PowerShell command for removing dead library servers is not so helpful as it doesn’t have a “Force” flag and it comes up with an error saying it can’t be contacted:
Luckily as the SCVMM backend is controlled by Sql server it wasn’t too difficult to find where the definitions of the library server were stored. Just connect to the SCVMM database instance ([YOUR_SCVMM_SERVER]\MICROSOFT$VMM$) and the table you need to look at is the tbl_ADHC_Library table. Firstly do a select on the table to get the GUID/UNIQUEIDENTIFIER of the library server(s) you need to delete:
From this query take the LibraryID field and for each of the library servers you need removing, run the following command:
exec prc_ADHC_Library_Delete '[LibraryID]'
Hey presto all the dead servers are now gone!
As always please make sure you have a backup and don’t blame me if you break your SCVMM server!!
Thanks to Barry O’connor for sponsoring me on my charity challenge!
Take a gander at his blog which can be found here and you may learn a thing or two! I certainly did, apparently Barry has so much spare time he can answer lots of questions on StackOverflow! Oh to be a contractor!! 😉
Thanks to SharpCrafters (the makers of PostSharp THE AOP framework for .Net 🙂 ) sponsoring me on my Princes Trust charity challenge I have had the great idea of giving away free plugs to your site and/or product if you sponsor me.
Any amount will get a thank-you blog post but if you sponsor me £100 or more you will be able guide the content of the blog-post (within reason! 😉 ). If you have donated over £100 DM me (@caveman_dick) and I will send you details of how to contact me!
As SharpCrafters were the first they even get a banner!
Currently our source tree is very similar to the recommended OpenWrap layout other than one difference, the “src” dir is called “Source”. This only causes an issue when it comes to building the wrap itself as by default the command tries to find any projects in the src folder. It’s a simple config change to get this to work, just add the following line to your .wrapdesc file:
build: msbuild; project=[PathToTheProject]\[CsProjFile]
Thanks to SerialSeb for an awesome package manager and super-quick support via twitter! 🙂