inherit the proper app.config in a program started from context menu by SharpShell

Question

i'm trying to develop an c# app integrated with the windows shell, because of this i'm using the sharpshell library. i'm using the sharpshell library directly in the same project, creating a dedicated class for handle the context menu. originally i linked to the click event on the context menu the following command:

System.Diagnostics.Process.Start(path, _command.ToString() + "|" + string.Join("|", SelectedItemPaths));

and the system was working. now i'm trying to start directly from the Click event a new istance of the Program.Main class with the following code:

            DmsDrive.Program.Main(new string[] { _command.ToString() + "|" + string.Join("|", SelectedItemPaths) });

and the istance is working and starts properly. the problem is that starting the process using this method make the programm to look for app.config into the windows directory (the main currentdomain is the explorer.exe process). because of this the app.config isn't loaded and the contract to the wcf service don't works.

do you know how can i handle this? or is it better that i continue to use the Process.start method?

Regards.

Answer 1

I would recommend starting the process directly using the Process Start function - I think if I'm reading your post properly, you're actually directly calling the 'Main' function of your program, which means you're not actually creating a new process at all (just calling a function in the Windows Explorer process which is what the shell extension is loaded into). This means that the program you're running is running in the process of the Windows Shell, which is not too friendly, as if it crashes, it can crash explorer.

Kick off the program using Process start. If you need to configure how it will connect, consider passing command line arguments to your program (such as a service address) and building the WCF client binding manually (in fact, you may find that once you've got used to creating WCF clients programmatically, they config file method is more long-winded and less intuitive!)

As a last option, for serious Windows software architectural over-the-top-ity, you could create a Windows Service that hosts a 'coordinator' service of some kind. The shell context menu can invoke the coordinator service (saying 'do something') and the service can kick of the process, or the process can start on start-up and poll the service if it needs to do something.