C# .NET - URI formats are not supported.

Asked By Greg on 25-May-11 06:55 PM
The following code is contained within a UserControl and runs just fine in the emulator(s) as well as a real mobile device, however, when using the VS2008 Designer to view the form which contains the UserControl, I get the error "URI formats are not supported." I'm using C#, with .NET CF 3.5.
Code:
string strAppDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase);
string[] files = Directory.GetFiles(strAppDir, "*.xml"); //<- Designer indicates error is here.

Granted the path contained within strAppDir does contain the following "\\Program Files\\AppConfigTest" however I don't understand why the designer is complaining. I've tried replacing "\\" with "/" but the designer still complains.  
Any assistance would be greatly appreciated.
Thank you.
Robbe Morris replied to Greg on 25-May-11 09:49 PM
GetFiles is expecting the drive letter to be included in the path in this case.
Ravi S replied to Greg on 25-May-11 10:02 PM
HI

To get just the full filename, I'd use:

Uri uri = new Uri(hreflink);
string filename = Path.GetFileName(uri.LocalPath);
refer the links
http://stackoverflow.com/questions/1105593/get-file-name-from-uri-string-in-c
http://stackoverflow.com/questions/2887924/invalid-uri-the-format-of-the-uri-could-not-be-determined

Greg replied to Robbe Morris on 26-May-11 12:00 AM
Mobile devices, at least the ones I've developed on, don't have drive letters. So I'm not sure how this helps me, but thanks anyway.
Greg replied to Ravi S on 26-May-11 12:13 AM
Thanks for the help, but your example, and related links, do not help me with my issue. Your examples are showing how to get a single file name. I'm trying to get all of the XML file names in the given path of "\\Program Files\\AppConfigTest", hence the GetFiles method. But apparently that method doesn't like the fact that there's no drive letter on the path (when working within the Visual Studio Designer). When running my original posted code on a smart device emulator or an actual smart device it works fine. My problem is with the VS Designer not liking the fact that GetFiles is trying to use a UNC Path (i.e. no drive letter). So I need to know either one of two solutions: 1) How to stop the VS2008 Designer from complaining about the Directory.GetFiles method, or 2) use some other method that will provide me with an array of file names matching a wildcard pattern, which the VS Designer won't complain about. Remeber the code that the designer is complaining about is in a Smart Device UserControl, and when placing that UserControl (DLL) on a Form, in another project, the VS Designer throws a fit and indicates "URI formats are not supported." Any ideas on the proposed two solutions?
I'm sorry, I didn't pick up on the mobile device piece
Robbe Morris replied to Greg on 26-May-11 12:27 AM
Knock me for not paying enough attention.  I looked up an old .NET CF 1.1 app I did that looked in the My Documents folder.  The path I used was "\My Documents\".  I don't recall why I opted to use the My Documents instead of the path to the exe.  This was numerous years ago.  However, it might have been a permission issue on the actual device that wouldn't necessarily show itself in the emulator.

The url is here.  It uses much the same tactics you are using:

http://www.eggheadcafe.com/articles/compactframeworkencryption.asp
Greg replied to Robbe Morris on 26-May-11 01:11 AM
Thanks Robbe, but what you mentioned, and in the example link, the path is hard-coded as:
private string LocalPath = @"\My Documents\";
I do not want to use a predefined path, as the UserControl I'm creating will be used in a wide-range of mobile devices produced by various manufacturers, so I don't feel confident in using a hard-coded path as it may not exist under all OEM versions of the OS. What I'm still looking for is a way to use an Attribute of some sort to stop the VS Designer from evaluating that chunk of code, or the method itself, where the GetFiles method is called, but only during design-time. Otherwise, I have to some up with some other method of getting a list of files using a wildcard. Thanks again though!
The bigger point
Robbe Morris replied to Greg on 26-May-11 08:49 AM
was that I think the problem is that you don't have permission to write to your program folder.  I think if you test your exact code with My Documents, it will work and confirm my conclusion.

That said, your .NET CF app will only work on Microsoft mobile operating systems that have the .NET CF installed.  My Documents is pretty standard on all of those operating systems.
Greg replied to Robbe Morris on 27-May-11 03:38 AM
To be honest Robbe, I don't think you're paying much attention to my actual problem. What gave you the idea that a Permission Issue at at stake here??? My code runs justs fine. under the emulators and real smart devices, plus I'm running Visual Studio 2008 in Administrator mode, so permissions are not an issue. Period.

Try to stay focused here... The problem is with the VS2008 Designer. So why, where, when and how does the Designer, complaining about URI Formats, equate to a permission issue? You've already stated that Directory.GetFiles() does not like to operate on paths without drive letters, so I'm still confused as to why you'd mention permissions?? It's a URI Format problem.

If you, or anyone else, can answer the following, precisely, then I'd be very grateful: How can I gather an array of file names, on a specified path (like "\\Program Files\\MyApp\\" in C#), using a wildcard, like "*.xml", WITHOUT using the Directory.GetFiles() method? Hell, I'd be happy with some Unmanaged API Call(s) if that's what it'll take to keep the VS Designer from complaining when it runs across this, in a UserControl, on a client form:
String[] files = Directory.GetFiles(strAppPath); //where strAppPath = \\Program Files\\MyFolder

Sorry, for the attitude, but I'm getting frustrated...
I thank you, anyone, in advance, for an actual solution to this problem!!
Did you try my suggestion?
Robbe Morris replied to Greg on 27-May-11 09:02 AM
At least to test if this was the issue?

What gave me the idea was 12 years of building all sorts of applications and not take anything for granted or make any assumptions.  So, when I run into frustrating problems, I nail them down step by step until I find the exact issue.

The emulator is an emulator, not an actual device.  You will run into issues where things behave differently on the actual device.  I really think this is either a permission issue "on the device" masked by .NET exceptions that don't tell you the exact problem (nothing new here...) or the path needs to just have one slash instead of two.
Greg replied to Robbe Morris on 29-May-11 12:58 AM
Sir Morris,
I did try your suggested method of using \\My Documents\\My Folder as a hard-coded path and as expected (by you) the Direcotry.GetFiles() method did NOT cause problems with the Visual Studio Designer. I became intrigued, reverted all code changes back to my previous version, to use the string returned by Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase); and could no longer reproduce my intital problem!!!!???

I thought I had reverted the code back to it's original, Visual Studio Designer error generating condition, but I hadn't. I had made the string path variable, previously local to a private method, a class instance variable instead (initialized in the class constructor) and used this.appPath in the .GetFiles() method. Once I reverted the code back one more previous revision, making the variable local to a method, and assigned it to Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase); did the Visual Studio Designer once again indicate that "URI formats are not supported."

So I thank you very much, for pointing me in the direction of trying \\My Documents\\. However, can you possibly explain why stoiring the app path in an instance variable (member), rather than a local method variable, made the difference??? 

I thank you profusely for your invaluable assistance in this matter. And again, my apologies for the frustrated, stress-induced, attitude previously... Thanks for helping me though it. :)