Annoying problems

jQuery Date Validation in Chrome

EltonStoneman — Thu, 29 Oct 2009 19:20:53 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

We had a fiddly issue with date validation in an ASP.NET MVC page failing for a valid date in Chrome, but passing in Firefox, IE etc. Tracing through our own code and xVal, the issue was narrowed down to the jQuery validation plugin (jquery.validate.js). For simple date validation, the library instantiates a date object from the given text value and lets JavaScript raise errors for invalid dates:

date: function(value, element) {

return this.optional(element) || !/Invalid|NaN/.test(new Date(value));

Chrome seems to ignore the current locale when it creates the date object, so a valid date in UK dd/mm/yy format – 29/10/2009 – fails as Chrome seems to interpret it in US mm/dd/yy format. Easy to test outside of all other code by entering some simple JavaScript into the address bar:

javascript:new Date('29/10/2009').toString()

Which Firefox renders as expected:

- as does IE (even IE6):

- but which Chrome renders as an invalid date:

You can also test it by navigating to the jQuery date validation sample page, and checking results for the same date in different browsers.

The fix is a simple change to the jQuery script to force the use of the current locale:

// http://docs.jquery.com/Plugins/Validation/Methods/date

date: function(value, element) {

//ES - Chrome does not use the locale when new Date objects instantiated:

//return this.optional(element) || !/Invalid|NaN/.test(new Date(value));

var d = new Date();

return this.optional(element) || !/Invalid|NaN/.test(new Date(d.toLocaleDateString(value)));

Hacking the Assembly Manifest

EltonStoneman — Wed, 11 Mar 2009 22:44:28 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

I was debugging a particularly nasty problem and found myself wanting to edit the manifest of a compiled .NET assembly, to change the version number of the assemblies it was referencing. Not necessarily best practice, but in this case it would enable me to confirm the exact issue without a two-hour build-and-deploy cycle. Turns out that nasty hacks like this are very straightforward:

Run ILDASM, open the assembly and choose File…Dump to extract the IL
Open the IL file in Visual Studio and edit the manifest – in this case, the version numbers of the referenced assemblies are easily found at the top of the file:

// Metadata version: v2.0.50727
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
.ver 2:0:0:0
}
.assembly extern x.y.z
{
.publickeytoken = (E4 21 0D 54 23 66 A2 B4 ) // . .D'f..
.ver 1:0:9:12
}
Save the IL and reassemble it with ILASM – if the assembly was signed, re-sign it using ilasm /DLL x.y.z.il /KEY=x.y.z.snk
Ensure the new assembly has the same name as the original, and it will operate as an exact replacement, only now its dependencies will be for the modified versions.

Simon McEnlly's article on CodeProject describes going further with the manifest to change the visibility of methods, and generally modifying and rebuilding assemblies where you don't have the source code. Note that if the assembly is signed and you don't have the strong name key to re-sign it, the modified assembly will warn about being tampered with and won't load.

Wix Errors ICE50 and ICE64

EltonStoneman — Sat, 13 Dec 2008 02:18:46 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

If you're creating shortcuts in a Wix package, Alex Shevchuk's post From MSI to WiX, Part 10 – Shortcuts is a great resource to follow. As it does, Wix has moved on, and Alex's scripts don't build in the current version (3.0.4318.0 on my box) – the LongName attribute has been deprecated, so remove any instances you find and put the full name in the Name attribute (Wix now takes care of generating a short name).

You may also find a couple of Internal Consistency Evaluator errors:

ICE50 - shortcut icon extension doesn't match shortcut file's extension, so the shortcut icon won't be correct
ICE64 - shortcut folders not being tagged in a RemoveFolder element so they're removed on uninstall

I couldn't fix ICE50 as I was pointing to a .htm file and didn't fancy hacking its extension to .exe to keep Wix happy, and although ICE64 is easy to fix (Alex describes how to do this), I'm generating the Wix script with T4 and it proved fiddly to inject the RemoveFolder elements under the correct Component element. So I tried linking and ignoring the errors, just to confirm my shortcuts were creating correctly. The error suppression syntax is:

light -out <outputMsiPath> <inputWixobjPath> -cultures:en-us -sice:ICE50 -sice:ICE64

This built the MSI, and the installer ran correctly. The interesting thing is that the .htm shortcut did have the right icon, and when I uninstalled the package, my shortcut folders were removed too. So it seems ICE50 and ICE64 can be safely suppressed without affecting the user experience.

Networking Virtual PCs with the Same Computer Name

EltonStoneman — Fri, 12 Dec 2008 00:59:09 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The aim of putting together a single VM and sharing it around a dev team soon hits the problem that multiple computers with the same name are trying to connect to the Windows network. The first VM to connect will be correctly registered, but subsequent images will get a network error: "Computer name already exists".

The problem is that you once you build up a dev environment (with SQL Server, BizTalk etc.) the computer name quickly becomes integral and changing it is very difficult (in the case of BizTalk, sufficiently difficult that it's not worth even trying). Having a base image with just the operating system means new copies could be taken and the name changed easily – but that defies the point of having one configured machine, as every new joiner needs to install the rest of the environment themselves.

A couple of alternatives are available:

Alan Smith describes setting up a partial image using SysPrep and scripts which run the first time a new image is used. Each VM then has a unique name and the scripts handle the remaining installations. This sounds like a good solution for full integration with your network, but there are additional setup costs and it's not much help if you already have a VM in use;
Simon Hutson uses a combination of network adapters in Virtual PC to hide the VM's computer name from the network, but still have access via the host machine. This sounded exactly what I wanted, but I couldn't get it communicating on the network with DNS, only using IP addresses (my VM is not configured as a DNS server so that may be the issue – but setting up DNS on the VM seems like overkill unless you need it anyway).

My solution is an extension of Simon's, basically using Shared Networking in Virtual PC , disabling Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks and WINS so the VM doesn't try to register itself with the network. You also need the second network using the Loca adapterl, which you configure with a static IP – an address in the range 10.0.0.x, and a subnet mask of 255.255.255.0 works consistently – and specify your network's real DNS servers.

This gives you TCP/IP access, and then you can resolve the machine names you need to connect to using the HOSTS file local to the VM. Obviously this is only suitable for accessing machines on the network with static IP addresses, and means network machines can't connect to your VM by name, but if you can live with that it's a very simple workaround. The image can be set up with the network adapters configured, and the HOSTS file already prepared so it's ready to go for new joiners.

Note that Windows Server 2003 as a guest OS will need to use a dedicated DNS address for the Shared Networking adapter: 192.168.131.254 – see Virtual PC Guy's post on using NAT with W2K3 for details on this.

In case it's been a while… The HOSTS file is a simple IP address/computer name lookup table which you'll find in %SystemRoot%\system32\drivers\etc\ (by default), which you extend by adding entries on a new line. Mine looks like this:

127.0.0.1 localhost

10.5.1.1 SVRNAME1

10.5.1.2 SVRNAME2

- and now we have multiple Virtual PCs with the same name connecting to the network, and happily using source control, database and build servers, without trashing our BizTalk install. A script to refresh the HOSTS file from a central location is a simple extension if your list is likely to change.

Wix error -532459699

EltonStoneman — Fri, 25 Jul 2008 20:43:14 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Running Wix 3.0.2420.0 I got an "object reference not set" and this error message when calling light.exe from an Exec MSBuild task:

The command ""..\bin\Wix\light" -out "c:\x\y\z\x.y.z.msi" "c:\x\y\z\x.y.z.wixobj" -ext WixIIsExtension -ext WixUiExtension -cultures:en-us" exited with code -532459699.

Annoyingly, I could run the exact same command in a command prompt immediately after the build failed, and it worked fine - and this error only happened on the build server and not on the dev boxes.

Before diving into it too much, I updated to the latest version of Wix (currently 3.0.4318.0) and the problem went away. So that solved that issue and just left me with "should we be using beta software even if it works for everything we need at the moment"…

Corrupted Files on Virtual PC Disk

EltonStoneman — Sat, 21 Jun 2008 01:00:17 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

One of the nice advantages of developing on a virtual image is that you can set it up with one drive for the OS and another for data. Your dev toolset is ready for project joiners to use, and copying a 15Gb file is far quicker than installing your toolset from nothing. When you want to take work home or on the train with you, it's just a case of zipping up the 1Gb data drive and copying it to your laptop.

I've been doing this using Microsoft Virtual PC once or twice a day for the last few months, and it's somewhere like 99.99% faultless. But that 0.01% fault is manifested as random files being reduced to zero-bytes. They have the correct name and are in the expected location, but are missing their contents. So suddenly a project fails to build as one of the class files is empty.

This seems to be a result of occasionally resizing the .vhd file, rather than with repeatedly zipping and unzipping it. I haven't got an answer for the cause, but the following PowerShell script will output all the zero-length files you have on disk:

##FindZeroByteFiles.ps1

param([string[]] $paths)

function Main

{

foreach ($path in $paths) {

$list = Join-Path $path zeros.txt

Remove-Item $list -ErrorAction SilentlyContinue

get-childitem $path -recurse | sort Length | foreach {

if ($_.Length -eq 0) {

$_.FullName >> $list

}

. Main

Usage – to list all the zero byte files on drives F and G:

.\FindZeroByteFiles.ps1 F:\,G:\

This will output a file called zeros.txt in the root of each drive specified.

I'll be running it more frequently and I'll update this post if I track down which part of the process is mangling those files in the virtual drive. Or if I get around to writing a heftier script which compares two virtual drives using VHDMount.

The identity of application pool, 'ESBAppPool' is invalid

EltonStoneman — Mon, 26 May 2008 21:16:07 GMT

While I was finishing up the "ESBSimpleSamples" project, I came across this strange error. On submitting a message to the ProcessItinerary Web service I got a 503 Service Unavailable error, and the event log showed the app pool had been shut down, with The identity of application pool, 'ESBAppPool' is invalid and error code 80070532.

A quick Google suggested it was an issue with the BizTalk isolated account. I hadn't changed it at all and the service was fine a couple of days ago, but I checked the BTSISOSVC account. It was flagged as "User must change password at next logon" which seemed odd. Removed that and set it to never expire, restarted IIS and it all started working again. Odd.

There is no build provider registered for the extension ‘.rem’

EltonStoneman — Thu, 24 Apr 2008 14:03:59 GMT

This is an ASP.Net error I got while converting a .Net Remoting app from 1.1 to 2.0, and it puzzled me for a while. The conversion had gone fine and everything built and deployed without a problem, but the unit tests I'd written were failing to find the remote service. IIS was being used as the host for a handful of wellknown objects, so I tried browsing to the WSDL and this was the error.

Check on Google and you'll see there aren't any relevant hits, so obviously something strange in the setup of this app. The stack trace (HttpRemotingHandlerFactory - WebServiceParser) suggested ASP.Net was trying to compile the .rem files. I set up a simple Remoting app hosted in IIS which worked in the same environment, and checked to see what was different.

The problem was that the 1.1 app had .rem files saved in the virtual directory of the Remoting service, so the request was finding the physical file and trying to build something from its contents. In 2.0 the .rem files are created on the fly when they're requested, so they get routed to the correct handler. After deleting the .rem files, everything was fine.

Surprising that this hasn't been seen anywhere else, but it's documented now.