Mercurial and Kiln

Posted on by
Reply

I’ve been working with the FogBugz bug tracker for quite a while now and I noticed that they offer a Mercurial based online version control system named Kiln.

I’ve been wanting to adopt one of these new-fangled distributed version control systems for some time now, so I decide to dive in and find out what all the fuss was about.

I read Joel Spolsky‘s excellent Mercurial tutorial, Hg Init and then set about installing Mercurial clients on all of my various workstations.

I ended up with TortoiseHG on my PC and MacHg on my Mac and so far I’m finding it to be a very flexible and easy to use system.

If you’re using Subversion or some other old-school version control system you should definitely take a look at Mercurial or GIT and see what you’re missing out on!

Dropbox

Posted on by
Reply

If you don’t have Dropbox installed, GO GET IT NOW!

www.dropbox.com

Dropbox is a program that lets you easily share and sync files amonst all of your computers (and phone).

It creates a folder that is automatically synchronized with all of the computers that you’ve installed Dropbox on. You can create a folder hierarchy and there is a public folder that you can put files that you want to share with others.

When you put a file into the public folder, you can right click and obtain a URL for that file, then you can send that URL to someone in an email or IM, and they can access the file just by clicking the link.

You can share folders with other Dropbox users, make it easy to share files amongst a group of people.

It also keeps a version history of the files allowing you to go back in time and access prior versions.

You can also access your drop box from any web browser anywhere you are, even if you don’t have your computer with you.

It’s really a great tool that has eliminated the need for me to carry a usb flash drive.

Go check it out now!

Dealing with the latest form of DLL hell

Posted on by
Reply

I’m working on a project which integrates a lot of legacy C++ code in several DLLs with a C# wrapper application.  Of course, the legacy code also references several third party libraries, just to make things interesting.

Everything was going well until I tried to run the application on a test VM and it displayed a very unhelpful error message:

This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem.

The first thing I discovered, was that in order to run exectutables on a test machine that are linked to the DEBUG versions the VC runtime libraries, I’d need to copy the appropriate folders from the C:Program FilesMicrosoft Visual Studio 9.0VCredistDebug_NonRedist folder to the executable’s directory on the test machine.  Here’s some relevant information on MSDN regarding this:

http://msdn.microsoft.com/en-us/library/aa985618(VS.80).aspx

Unfortunately this was just the tip of the iceberg.

After copying the correct runtime library DLLs, I was still greeted with the same error when I tried to run my application.  The system event log contained a clue in the form of a SideBySide error:

A component version required by the application conflicts with another component version already active.

Hmm.  Some component wasn’t playing nice with some other component!

After a lot of googling, I ran across this Stack Overflow question which led to the eventual resolution:

http://stackoverflow.com/questions/59635/app-does-not-run-with-vs-2008-sp1-dlls-previous-version-works-with-rtm-versions

Apparently, some of the third party libraries were causing the linker to reference older VC runtime library versions, so our component’s manifest file was listing multiple versions.

This was apparently what was causing the problems on the test machine.

The fix was to add the following to the pre-processor directives for each of our projects which forces everything to reference the latest runtime libraries:

_BIND_TO_CURRENT_VCLIBS_VERSION

If you run into this, pay attention to this paragraph from the accepted answer which details a great way to debug this problem:

A great way to debug which libraries don’t have the preprocessor directives set: temporarily modify your platform headers so that compilation stops when it tries to embed the old manifest. Open C:Program FilesMicrosoft Visual Studio 9.0VCcrtincludecrtassem.h. Search for the ‘21022’ string. In that define, put something invalid (change ‘define’ to ‘blehbleh’ or so). This way, when you’re compiling a project where the _BIND_TO_CURRENT_CRT_VERSION preprocessor flag is not set, your compilation will stop and you’ll know that you need to add them or made sure that it’s applied everywhere.

This tip really helped me to identify and correct the projects which where causing the problem.

It’s amazing to me how far we’ve come from the days when this type of problem was routine.  With the advent of .NET, this sort of thing is rarely a problem until you try to use some old C++ libraries.  I hope you never have to deal with this sort of thing!