I had the opportunity to assist one of my co-workers today in troubleshooting a web service + Silverlight client I had built for a customer a while back. The combination of the two enables users to upload large files to a server over intermittent internet connections. My co-worker mentioned that she got an error message in a message box from the Silverlight client stating that something was wrong with the parameters sent to it.

In the end it turns out that the parameter for the maximum file size allowed to upload had been set to 3 GB. The specification I received when building this stated that the maximum file size that the system should be able to handle would not exceed 1 GB. So I figured a regular int would suffice for managing the maximum file size restriction.

So what this malconfiguration gave was that the Silverlight client tried to stuff the value of 3GB into an int – this is a no go. My co-worker is not to blame for this, she just got this particular setup handed to her from someone else.

What you specify is what you get.

While preparing my MacBook Pro which I bought for myself on my 30th birtday this Wednesday one of the things to get done was to get the 3G-modem to work. Having used the modem on my various Windows-machines before I knew that a OS X installer was lying around on the internal memory, so I just fired it up. Sadly it turned out that the Launch2Net installer failed, so I proceeded to uninstall it.

After awhile I found a newer version of Launch2Net which allegedly is Snow Leopard compatible (I need to learn that 10.x releases actually differ quite a lot internally from time to time), so I downloaded that one and installed it. Only problem now was that even though the manual claimed that the software would fire up automatically when the modem was inserted nothing happened! No matter how many times I uninstalled the software, rebooted or removed it with AppCleaner and then re-installed it. No go.

By now I started wondering if the rollback of the first installer hadn’t ended cleanly. Long story short, after learning that drivers aren’t what drivers are in Windows but are rather installed as kernel extensions I began looking for where these extensions are stored, the answer is: /System/Library/Extensions. Well, lo and behold – even after having uninstalled all visible traces of the software there were extensions left (named NMSonyEricsson[...]). After having manually deleted these extensions (which actually are folders containing binaries and other stuff) I rebooted and then installed the latest version of Launch2Net SonyEricsson Edition (the link is specifically for the modem I have (SonyEricsson MD400) which in my case happens to be 1.9.1.0 and then rebooted again.

Now it all works! The software fires up when I plug in the modem and it configures itself according to the network the SIM card belongs to and I’m able to connect. I’ve been listening to Spotify for the past 40 minutes now without a hitch – so I’m happy!

What I’m taking away from this is that I continue to not be surprised by the crappy quality a lot of cell network providers have to live with when distributing hardware for which someone else provides the software. Especially when we’re talking about a niche operating system like Mac OS X.

Now that I’m in between assignments I thought I’d take the opportunity to install Windows 7 on my work laptop (a HP 8510w) in order to get better performance in my virtual machines. Several colleagues have already installed Windows 7 on their laptops of the same model, so I figured I’d take the plunge.

A colleague recommended that I should use a USB drive to install from as this would save me a lot of time and since I had read about the tool that Microsoft har released for this I figured that I would give it a go. Turns out that I had to download the tool from a CNET server because the tool has been pulled by Microsoft due to a license problem. Went ahead and prepared my 4 GB USB stick with the ISO and rebooted.

After having clicked the “Install Now” button all I get is a dialog telling me that I’m missing a CD/DVD device driver and tells me that I should browse for a location containing the drivers needed. That is misses a working driver is, in my view, utter bullshit. Why? Because when I browse for the drivers (which I don’t have by the way, because who needs drivers for a CD/DVD drive nowadays?) I can browse my hard drive (so it’s not a problem with not having a working hard drive to install to), a CD inserted into the CD drive, and the contents of the USB stick containing the Windows 7 installation.

Googleing the problem shows a bunch of people having this problem due to faulty burns of their DVDs, but this doesn’t apply to me since I’m using a USB stick to install (but I did re-prepare the USB stick three times just to be sure). The few people I’ve found that have had this problem haven’t had it with earlier versions of Windows 7 (betas and release candidates) and some of them seem to have cured the problem by changing the SATA configuration in their BIOSes (i.e. changing from SATA mode to IDE mode). One Microsoft site even suggests that the controller in the computer is not compatible with the AHCI driver provided by Microsoft. How the heck could it not be compatible when it’s been working without a problem in Windows Vista? Actually I thought about changing SATA settings in the BIOS, but I didn’t find any settings which solved this problem.

Tomorrow I’ll try to install from a DVD which is known to have worked for a bunch of my colleagues and see what happens then. But somehow I don’t really beleive in success. After having re-prepared the USB stick three times the corruption problem is most likely not what’s causing this, so it’s more likely that i’ve got a weird hardware revision of the laptop which screws this up.

Things like this want me to get a MacBook Pro and just forget about problems like these! Atleast there’s a greater chance to get Windows working virtually…

So, as a part of my current consulting assignment I’ve been asked to work out a way of documenting the integrations that are deployed in the BizTalk 2006 platform I’m working with. I’ve stumbled across a tool called BTM2HTML/BizTalk Map Documenter (a codeplex project), but the main problem with this tool is that it only documents BizTalk maps. Orchestrations or pipelines and so forth are left out of the equation. Also the presentation of the mapping wasn’t really useful to us, it was somewhere in between technical and end user friendly. A developer wouldn’t be happy with it because it’s too much of a user presentation and the user wouldn’t be happy with it because he/she wouldn’t understand it fully.

What I set out to find was some tool that would help me extract the generated XSLT from a BizTalk map (either from the .btm-file or the assembly) and preferably not require me to manually load over 1500 projects in one instance of Visual Studio (and then right-click every single map to select “Validate map”). After asking around I got this tip: BizTalk Server 2006 Documenter (also a codeplex project). This looked exactly like what I wanted! Everything in my BizTalk platform would be documented in detail and neatly packaged into one comprehensive file. Only problem: it threw an exception when I tried to document my local BizTalk server!

It turns out that the application (or well, rather the base library that the application uses (BizTalk OM, yup – another codeplex project)) has issues with multiple versions of the same binary being installed on the same BizTalk server (i.e. in the servers assembly cache (GAC)). For some weird reason a design decision was made to store the map names, orchestration names, pipeline names, schema names and assembly names without version information as keys in a hashtable. It comes to no surprise that when confronted with a second version of for example a pipeline the application will encounter an exception due to the fact that the name already exists as a key in the hashtable storing pipelines for the current BizTalk application.

So for the last couple of days I’ve tried to spend as much time as possible extending the base library so that it will be compatible with BizTalk installations that have multiple versions of the same map names, pipeline names, orchestration names and assembly names. To be brutally honest my solution isn’t the most elegant, but it works. All it does is append the version of the artefact in question to its name when the instance of the type is created. What should be done is rather some re-engineering of the way the class library is built and how the inner collections are stored. Also, I don’t know if I’ve missed some artefact type which should be extended in the same manner just because it isn’t used in our server.

I’ll see if I can get in touch with the persons responsible for the various bits and pieces I’ve changed in order to add my efforts to the project or atleast receive some feedback. If you should feel that my changes would make your life better before I’ve managed to add them to the official project you can always contact me through this blog and I’ll be happy to send you the code (or even the packaged installation) – the license permits this from what I can see.

(Of course there’s a slight chance that I’ve completely missed something about all this multi-version yahoo which solves my initial problem with the exception, but if so – I haven’t found it yet).

Today I’m going to do something that is against my standards. I’m going to deploy stuff to a production environment on a friday.

Generally it’s a bad idea to deploy things in to production on fridays and some readers might wonder why. Well, do you like working weekends? Thought so. If something can go wrong with the package you’re deploying it most certainly will go wrong if you’re deploying it on a friday – it’s like asking for it!

Ah well, sometimes you just can’t choose. As I like to say: The money always wins. And by that I mean that the people in charge of the money always tend to win, and if they want the deploy on a friday they get the deploy on a friday.

If you’re in the same business as me – try to stay away from deploys on fridays if possible, but don’t break your back over it. Because that’ll be you dying, not them. =)

Found this post which most definitely is going to help me next time I have to debug slow running or seemingly dead processes/threads. If I have to I’ll get a dump of the process and analyze it, but to be honest I wouldn’t mind not having to . =)

This is what it looks like: