How do I get the path to the exe of another installed application onthe machine

[jake]

After I generate a list of installed applications by getting the
DisplayName value of the subkeys of the following 2 registry keys:

hkey_local_machine\Software\Microsoft\Windows\CurrentVersion\Uninstall

and

hkey_current_user\Software\Microsoft\Windows\CurrentVersion\Uninstall

(Or, if you have a better way, please let me know),

and then after I select one of them, and assuming it has an exe, how
do I get the path to that exe?

Your help is greatly appreciated.
jake

 

[Morten Wennevik [C# MVP]]

Hi Jake,

There may be many executables. The uninstall list has no concept of the
executable applications, msiexec cares only about which files, registry keys
etc was added during an installation.

To create a list of applications you may be able to use

hkey_local_machine\Software\Microsoft\Windows\CurrentVersion\App Paths

 

[con-man-jake]

Hi Jake,

There may be many executables.  The uninstall list has no concept of the
executable applications, msiexec cares only about which files, registry keys
etc was added during an installation.

To create a list of applications you may be able to use

hkey_local_machine\Software\Microsoft\Windows\CurrentVersion\App Paths
--
Happy Coding!
Morten Wennevik [C# MVP]

After I generate a list of installed applications by getting the
DisplayName value of the subkeys of the following 2 registry keys:



(Or, if you have a better way, please let me know),

and then after I select one of them, and assuming it has an exe, how
do I get the path to that exe?

Your help is greatly appreciated.
jake

Thank you Morten,
Fetching the app names from the Uninstall subkeys is undertaken simply
to make sure that the machine has a certain app. The app exe, (this
one has only one exe, the name of which is already known to me) needs
to be launched. So, ok, I get the issue that an app may have more
than one exe, as, I think I always did but, of course, hind sight is
always 20/20!

But here is the real scenario: Now that I made sure the machine has
the desired app, and since I already know the exe file name, how do I
find the path to that exe?
Note: The "Path" environment variable does not point to the app folder
(this one only has one folder), so I can't simply launch it using the
bare exe file name.

By the way, I had looked into the "App Paths" subkey prior to my first
post, but it only has a limited number of app exes, so, I need to look
elsewhere.
Any help is greatly appreciated.
Regards,
jake

 

[con-man-jake]

There is no rule that says an installation routine *HAS* to have a
corresponding uninstallation routine. It is usual, I'll admit, but by no
means 100% guaranteed...


You didn't - see above...

Mark,
Your points are valid, but...we are getting off track here. My
emphasis is elsewhere.

Although I get (and I always knew) that an installed app is not
guaranteed to have an uninstallation routine, the app I am trying to
look for is one of "my" apps. The folder where it is installed is
unknown. But, what is known is that it "WILL" have an uninstall
routine. This and other facts that may seem as assumptions to you are
concrete facts in our in-house development and data center
environment. Discussions regarding the proper ways to develop in-
house data center apps (and I admit, in which you did not engage) are
worthy of their own thread.

So, at this point, I am past determining whether a machine has the app
(I wasn't at the start of this thread, but now I am.)

The scenario is:

Now that I made sure (and yes, I did make sure) the machine has the
desired app, and I know the app exe file name, how do I get the path?
Regards,
jake

 

[Ben Voigt [C++ MVP]]

Although I get (and I always knew) that an installed app is not
guaranteed to have an uninstallation routine, the app I am trying to
look for is one of "my" apps. The folder where it is installed is
unknown. But, what is known is that it "WILL" have an uninstall
routine. This and other facts that may seem as assumptions to you are
concrete facts in our in-house development and data center
environment. Discussions regarding the proper ways to develop in-
house data center apps (and I admit, in which you did not engage) are
worthy of their own thread.

If it's your app, then have it create a registry entry containing the path.
Many apps do this so that the patch install utility can find the main
installation directory, for example.

 

[Family Tree Mike]

The scenario is:

Now that I made sure (and yes, I did make sure) the machine has the
desired app, and I know the app exe file name, how do I get the path?
Regards,
jake

You should use Path.GetDirectoryName("Full path to App.Exe"):
http://msdn.microsoft.com/en-us/library/system.io.path.getdirectoryname.aspx

 

[con-man-jake]

If it's your app, then have it create a registry entry containing the path.
Many apps do this so that the patch install utility can find the main
installation directory, for example.

Yes Ben, that is one of only a couple of options I have left, from
what I can see. The current app in development is looking for the
path the exe of a previous app. I just did not want to modify the old
app and redistribute again. But I guess I have to bite the bullet.

Another solution, which will also necessitate redistribution of the
old app is the file association trick whereby a unique file extension
gets associated with the old app at installation time, the other app
simply starts a file with that extension.

At any rate, I think your approach is slightly simpler.

 

[con-man-jake]

You should use Path.GetDirectoryName("Full path to App.Exe"):http://msdn.microsoft.com/en-us/library/system.io.path.getdirectoryna...

Mike, maybe I am missing something, but GetDirectoryName() needs the
full path string as a parameter. It will then simply dissect it and
return the path portion. If I have the full path then I don't have an
issue here anymore. Or, maybe I misunderstood.

 

[Family Tree Mike]

Mike, maybe I am missing something, but GetDirectoryName() needs the
full path string as a parameter. It will then simply dissect it and
return the path portion. If I have the full path then I don't have an
issue here anymore. Or, maybe I misunderstood.

I guess I am the confused one. I took your statement saying I know the
app exe file name to include the path.

Let's try a different approach. How does your user launch the application?

 

[Ben Voigt [C++ MVP]]

Yes Ben, that is one of only a couple of options I have left, from
what I can see. The current app in development is looking for the
path the exe of a previous app. I just did not want to modify the old
app and redistribute again. But I guess I have to bite the bullet.

Another solution, which will also necessitate redistribution of the
old app is the file association trick whereby a unique file extension
gets associated with the old app at installation time, the other app
simply starts a file with that extension.

At any rate, I think your approach is slightly simpler.

If your old app registered any COM classes, then the path probably already
exists as the InProcServer registry entry (or whatever the equivalent for
out-of-process servers is).



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4343 (20090817) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[con-man-jake]

I guess I am the confused one.  I took your statement saying I know the
app exe file name to include the path.

Let's try a different approach.  How does your user launch the application?

Mike, the user of the new app (also, of the old app) will launch it
from the program menu or from an icon on the desktop (both are
available.) The old app would have been running by then because it is
part of the Startup group of the Start menu. My dilemma is, what if
the old app has stopped running for some reason? Well, the new app is
supposed to start the old one again;...and therein lies the
difficulty. Hmmm,... as I am writing this, I am thinking maybe I can
start the link to the old app by pointing to the Startup group instead
of trying to find the real path to it.

So many choices, so little time.

At any rate, that is how the user starts it.
jake

 

[con-man-jake]

If your old app registered any COM classes, then the path probably already
exists as the InProcServer registry entry (or whatever the equivalent for
out-of-process servers is).

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4343 (20090817) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Ben,
Unfortunately, the old app has no COM classes. It is a simple app
that calls a boolean WCF service method that returns yay or nay
signaling whether a certain business event has occurred. If true, it
alerts the user by showing a window in the bottom right corner of the
screen and making it fade away after a few seconds. The app stays
running and performs the check periodically.
jake

 

[Family Tree Mike]

Mike, the user of the new app (also, of the old app) will launch it
from the program menu or from an icon on the desktop (both are
available.) The old app would have been running by then because it is
part of the Startup group of the Start menu. My dilemma is, what if
the old app has stopped running for some reason? Well, the new app is
supposed to start the old one again;...and therein lies the
difficulty. Hmmm,... as I am writing this, I am thinking maybe I can
start the link to the old app by pointing to the Startup group instead
of trying to find the real path to it.

So many choices, so little time.

At any rate, that is how the user starts it.
jake

That is exactly where I was going with the question. There must have
been a shortcut that has the path somewhere.

 

[Ben Voigt [C++ MVP]]

That is exactly where I was going with the question. There must have
been a shortcut that has the path somewhere.

But the end-user could have moved or renamed that shortcut while
reorganizing the Start Menu to suit their preferences.

 

[con-man-jake]

But the end-user could have moved or renamed that shortcut while
reorganizing the Start Menu to suit their preferences.

You are right, but the end user will be restricted in this case. That
is just the reality of our company. This product is not for public
consumption. It is not even for all employees at the company; it is
only for a handful of authorized personnel with highly controlled
machine setup. So, I am safe there. Should something fail, then
systems admin will be called to fix it.
This may not seem pretty to any of us, including me, but it will do.

 

[con-man-jake]

But the end-user could have moved or renamed that shortcut while
reorganizing the Start Menu to suit their preferences.

Ben,
You are right, but the end user will be restricted in this case.
That
is just the reality of our company. This product is not for public
consumption. It is not even for all employees at the company; it is
only for a handful of authorized personnel with highly controlled
machine setup. So, I am safe there. Should something fail, then
systems admin will be called to fix it.
This may not seem pretty to any of us, including me, but it will do.
jake