Set registry to control working dir when associating file-type with application

I'm using Inno for an installer, and I want to associate a file type with my app:

Root: HKCR; Subkey: ".rpl"; ValueType: string; ValueName: ""; ValueData: "MyReplay"; Flags: uninsdeletevalue;
Root: HKCR; Subkey: "MyReplay"; ValueType: string; ValueName: ""; ValueData: "Replay File"; Flags: uninsdeletekey;
Root: HKCR; Subkey: "MyReplay\DefaultIcon"; ValueType: string; ValueName: ""; ValueData: "{app}\bin\MyApp.ico,0"; Flags: uninsdeletekey;
Root: HKCR; Subkey: "MyReplay\shell\open\command"; ValueType: string; ValueName: ""; ValueData: """{app}\bin\MyApp.exe"" ""%1"""; Flags: uninsdeletekey;

Right now, double-clicking a .rpl file launches the app, but the working dir appears to be where the .rpl file is located, so the app crashes as it can't load any data. Is it posible to set the registry to control the start/working dir for file assoc开发者_开发百科iations as well as the app that is launched? Or does my app itself need to be able to work around this?

The point is I always want my EXE to run from e.g. c:\Programs\MyApp. If you click a shortcut or run it manually this is fine. The only exception I can find is when you double click on a file of a type associated with the app, Windows sets the working dir of the EXE to the location of that file.

The problem behind all this is I have a development build on my PC, and I also install the released version as a normal user would. I need to be able to run the dev version without it going to the registry and finding paths to the installed production version's files.

Even if there is a way to have a different working directory for your application specified in the registry - you should really fix this in the application. The reason is that there are multiple ways to open a data file with your application, and you simply can't fix it for all of them. Consider

D:\> c:\Programs\MyApp\MyApp.exe \\public\foo\data.ext

where a program is started with the name of the file (as UNC path) to open as a parameter, executed in a completely different directory. I do stuff like that regularly, and I expect applications to work under these circumstances.

Note that setting the working directory to the application root path first thing after start isn't a good idea either, as then relative paths will be wrong. A proper solution means changing the application in a way that it works correctly from whatever the current working directory happens to be, by using fully qualified paths internally.

Edit:

You comment

But then this means my app is totally dependent on the registry. Which is a pain for development testing, if every time I run my dev build it goes and loads all the files for the installed version

but that isn't necessarily so. You can read the path to the currently running executable, by using the GetModuleFileName() function or its equivalent wrapper in the GUI library (like Application.ExeName in Delphi). Setting the working directory from that path is easy, I just don't think it is a good idea, as changing the working directory breaks relative paths the user may expect to work. It isn't really true that

Windows runs the EXE from the location of the file you double-click. This seems to be the exceptional case, in other cases the EXE always runs from where I expect.

because there can be many ways how the application can be executed with a different working directory than the path to the executable itself. A well-behaved program doesn't make the assumption that these are equal. It makes using the application in scripts or from the command line so much harder.