No application is associated with the specified file for this operation

[r***@raymondjames.com]

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.

[Mark Rae [MVP]]

Post by r***@raymondjames.com
How can I tell if the operating system already has a file extension
associated with an application before I even begin?

I have a class for this which uses WinAPI. There may be a newer (WMI)
method - I haven't looked at this for a couple of years...

The class is as below - call it like this:

if (String.IsNullOrEmpty(FileAssociation.Get(".pdf")))
{
// do something
}
--
Mark Rae
ASP.NET MVP
http://www.markrae.net


using System;
using System.Runtime.InteropServices;
using System.Text;

public abstract class FileAssociation
{
[DllImport("Shlwapi.dll", SetLastError = true, CharSet=CharSet.Auto)]
static extern uint AssocQueryString(AssocF flags, AssocStr str, string
pszAssoc, string pszExtra, [Out] StringBuilder pszOut, [In][Out] ref uint
pcchOut);

public static string Get(string pstrExtension)
{
try
{
uint pcchOut = 0;
AssocQueryString(AssocF.Verify, AssocStr.Executable, pstrExtension,
null, null, ref pcchOut);
StringBuilder pszOut = new StringBuilder((int)pcchOut);
AssocQueryString(AssocF.Verify, AssocStr.Executable, pstrExtension,
null, pszOut, ref pcchOut);
string strExecutable = pszOut.ToString();
if (strExecutable.Contains("shell32.dll"))
{
return String.Empty;
}
else
{
return strExecutable;
}
}
catch (Exception ex)
{
throw (ex);
}
}
}

[Flags]
public enum AssocF
{
Init_NoRemapCLSID = 0x1,
Init_ByExeName = 0x2,
Open_ByExeName = 0x2,
Init_DefaultToStar = 0x4,
Init_DefaultToFolder = 0x8,
NoUserSettings = 0x10,
NoTruncate = 0x20,
Verify = 0x40,
RemapRunDll = 0x80,
NoFixUps = 0x100,
IgnoreBaseClass = 0x200
}

public enum AssocStr
{
Command = 1,
Executable,
FriendlyDocName,
FriendlyAppName,
NoOpen,
ShellNewValue,
DDECommand,
DDEIfExec,
DDEApplication,
DDETopic
}
}

[r***@raymondjames.com]

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.

[Mark Rae [MVP]]

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

1) Create a new class file

2) Drop the code I gave you into it

3) Call it in the way I demonstrated - how much simpler does it need to
be...?

In the meantime, I found that the OS (here, Windows XP) stores the

And what about next month when mainstream support for XP ends...?
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Windows+XP+Pro&Filter=FilterNO

[Pavel Minaev]

Post by r***@raymondjames.com
I have an application in which the user can double click on a file
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
"No application is associated with the specified file for this
operation"
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.

Post by r***@raymondjames.com
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).

[h***@gmail.com]

Post by Pavel Minaev

Post by r***@raymondjames.com
I have an application in which the user can double click on a file
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
"No application is associated with the specified file for this
operation"
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.

Post by r***@raymondjames.com
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).- 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.

[Peter Duniho]

Post by h***@gmail.com
[...]
This is so RARE event that you can't serionsly put this as an
argument.

I'll agree it's an even more rare possibility than, for example, file
structures changing during execution. But, "correct code" means it's
immune to externalities, not that it's hoping to be lucky.

The chances of my house catching fire, especially since I'm a non-smoker
and we don't use any space-heaters, is incredibly low. But we still have
insurance. Likewise, just because one has checked the state of the
configuration before attempting an operation, that's no reason to write
the code such that it assumes the operation will succeed.

In this case, there may be some benefit to checking before performing the
operation, since it may be that failure is more common than success.
Especially if the operation is attempted frequently. But that doesn't
mean the code trying to do the operation can afford to ignore errors.

Post by h***@gmail.com
No one needs to chane file associations more than once, including
installs.

That's completely false. It's not something I do on a regular basis, but
I certainly have changed file associations multiple times, both implicitly
through some behavior of a setup program or "first-run" logic in software,
_and_ doing it manually. It does happen, and assuming it doesn't is
what's "crazy".

Pete