I'm going to offer some different advice.

Personally, I wouldn't count on perl.exe being in the path. I don't know about IndigoPerl, but the ActivePerl installation gives you the option of adding the perl/bin folder to the path, but it's not mandatory.

I don't let setup programs add things to %PATH% (apart from a few special exceptions), because I want a bit more control over what gets executed, and where. So I generally add things to PATH manually, or write a quick wrapper to the executable that I want frequent access to. I'm not saying that it's a good or bad thing to do, but I don't think I am alone in guarding my environment variables.

This is my suggestion: install your own copy of perl along with your commercial application. The Perl licenses (Perl Artistic License) allow for this. You should simply be able to compile your own version of perl, add the modules needed (check their licenses too.) and include those compiled files in the setup distribution of the commercial application. This has several benefits.

• You know WHERE Perl is installed
• You know THAT Perl is installed
• You know what version of Perl is installed

The downside is of course, that you increase the size of your distribution by several MB. If you need a reason convince the bosses, tell them that you will be able to provide better support for your software and clients. If your clients run Perl already, it won't break your application if they upgrade it or add modules, or uninstall it, etc.

Just make sure you've covered all the licensing issues before you do this.

Update: I've just re-read your original post, and you package Perl with the application already. So perhaps it's not too far fetched to just bundle a compiled version with only the bits you need. It may even reduce the overall size, and you won't clobber a perl installation that may already exist.