PathTooLongException and Solutions?

[treddie]

Hi. I was reading the article: .NET 2.0 Workaround for PathTooLongException for a solution to the too long path name problem. In that article it states that there is a long, "W" version of the CreateFile() function. Now, the class he developed seems to support opening, reading and writing of files but not looking at the contents of a directory. I have two questions: 1. Is there an "easy" way to expand his class to include other functions such as listing directory contents? If so, what other functions would be required to pull this off? I have found such functions such as FindFirstFile(), but the documentation and Googling do not suggest that there are any "W" versions of these. UPDATE: According to MSDN, FindFirstFileEx() does not carry the MAX_PATH limitation, so in theory, it should work. 2. In his code, he does not include declarations for his API functions, although he does import namespaces. Is this because he is working in C# (which I am only partly familiar with)? I have converted his code from C# to vb.Net, but the online converter cannot necessarily know that declarations need to be added to the converted code, if in fact they DO need to be. My experience says, "Yes", it definitely does, but then again, why wouldn't those same Import lines work just as well in vb.Net? If that is where these functions are located, then why does vb.Net require explicit declarations? Is this so an entire library does not need to be loaded into memory all at once? Many thanks for any help! :) Below is his original code and usage, followed by my online conversion from C# to vb.Net:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Win32.SafeHandles;
using System.Runtime.InteropServices;
using System.IO;

namespace System.IO
{
class Win32File
{

    // Error
    const int ERROR\_ALREADY\_EXISTS = 183;
    // seek location
    const uint FILE\_BEGIN = 0x0;
    const uint FILE\_CURRENT = 0x1;
    const uint FILE\_END = 0x2;


    // access
    const uint GENERIC\_READ = 0x80000000;
    const uint GENERIC\_WRITE = 0x40000000;
    const uint GENERIC\_EXECUTE = 0x20000000;
    const uint GENERIC\_ALL = 0x10000000;

    const uint FILE\_APPEND\_DATA = 0x00000004;

    // attribute
    const uint FILE\_ATTRIBUTE\_NORMAL = 0x80;

    // share
    c

[Lost User]

treddie wrote:

In his code, he does not include declarations for his API functions, although he does import namespaces. Is this because he is working in C#

He does. You can browse the source code using the links in the article. His P/Invokes start on line number 46.

treddie wrote:

the online converter cannot necessarily know that declarations need to be added to the converted code, if in fact they DO need to be.

Bad translator.

treddie wrote:

why wouldn't those same Import lines work just as well in vb.Net? If that is where these functions are located, then why does vb.Net require explicit declarations? Is this so an entire library does not need to be loaded into memory all at once?

There's multiple ways to link/load a dll. The "using" or "import" lines are defining which namespaces to look in when searching for a specific class-type. Sometimes one needs to "add (a) reference" to an external assembly to be able to access types in other libraries. That's the usual route for managed code - anything in .NET. There's also a lot of unmanged code on the machine, as is the WinAPI. The code is also linking to a specific part in the WinAPI in "kernel32.dll". Both VB.NET and C# need special declarations for these, decorated with the DllImport attribute.

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

[treddie]

Cool. Tank you very much for your help, Eddy.

[Lost User]

You're welcome :)