No application is associated with the specified file for thisoperation

[richard.martino]

I have an application in which the user can double click on a file
name and my code simply says:

System.Diagnostics.Process.Start(filename);

The operating system determines which application to use from the file
extension (e.g., *.txt starts `notepad`);

For files that have not been configured someplace in the operating
system, I get the exception:

"No application is associated with the specified file for this
operation"

Yes, I can try/catch the exception, then re-issue:

System.Diagnostics.Process.Start("rundll32.exe", "shell32.dll,
OpenAs_RunDLL " + filename);

but, I do not like using try/catch as regular programming style, just
for genuine exceptions.

How can I tell if the operating system already has a file extension
associated with an application before I even begin?

Thanks.

 

[richard.martino]

Mark:

Thanks for the code sample.

In the meantime, I found that the OS (here, windows XP) stores the
association in the registry at:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
\FileExts

which I already know how to access in C#.

I did a _little_ bit of research concerning WMI, but nothing jumped
out at me.

So, I now have two less klugey solutions (less klugey than try/catch),
neither of which is a simple C# solution.

I was hoping that, because the exception was a
System.ComponentModel.Win32Exception, there might be some class or
method within the System.ComponentModel namespace that could be called
ahead of time to prevent the exception.

Thanks for your help.

 

[Pavel Minaev]

I have an application in which the user can double click on a file
name and my code simply says:

System.Diagnostics.Process.Start(filename);

The operating system determines which application to use from the file
extension (e.g., *.txt starts `notepad`);

For files that have not been configured someplace in the operating
system, I get the exception:

"No application is associated with the specified file for this
operation"

Yes, I can try/catch the exception, then re-issue:

System.Diagnostics.Process.Start("rundll32.exe", "shell32.dll,
OpenAs_RunDLL " + filename);

but, I do not like using try/catch as regular programming style, just
for genuine exceptions.

There's nothing wrong with using try/catch if the API you're using is
designed that way.

How can I tell if the operating system already has a file extension
associated with an application before I even begin?

Even if you insert the check, you should keep in mind that there's an
inherent race condition there: in theory, some other process may
create or remove the file association after you check and before you
act on the result of the check. In case of removal, you'd still get
that same exception thrown, so you should be prepared to catch it
regardless of any checks you do (this is exactly the same reasoning as
to why you have to catch FileNotFoundException in File.Open even if
you check for File.Exists first).

 

[hack2root]

There's nothing wrong with using try/catch if the API you're using is
designed that way.


Even if you insert the check, you should keep in mind that there's an
inherent race condition there: in theory, some other process may
create or remove the file association after you check and before you
act on the result of the check. In case of removal, you'd still get
that same exception thrown, so you should be prepared to catch it
regardless of any checks you do (this is exactly the same reasoning as
to why you have to catch FileNotFoundException in File.Open even if
you check for File.Exists first).- Hide quoted text -

- Show quoted text -

This is so RARE event that you can't serionsly put this as an
argument.
No one needs to chane file associations more than once, including
installs.
Overwise it will be absolutely crazy.