CopyFileEx returns different results based on VisualStudio 2019 vs VisualStudio 2022

[RFBomb]

I am not sure at all where to ask this question, so please let me know if there is a better forum for this.

I am one of the maintainers of the RoboSharp library, and am working on a PR to bring some custom implementations into existence for consumers. One of those will effectively be a wrapper for CopyFileEx, or its planned to be if all goes well (which its not).

The problem i have run into is that 2 of my unit tests fail when running via VS2019 Professional, and succeeds when running via VS2022 Community. CopyFileEx_CopyFile and CopyFileEx_CopyFileAsync (ignore CopyFileAsyncTest)

Test Environment:

• Windows 10 22h2
• VS 2019 / 2022
• RoboSharp.Extensions - Compiling for netstandard2.0;netstandard2.1;netcoreapp3.1;net5.0;
• Unit Test Environment -- Net472 ( so netStandard2.0 )

Test Overview:

• Fail the test if source file missing (succeeds)
• Write the source and destination file to disk (succeeds)
• Attempt to execute CopyFileEx using the 'FAIL_IF_EXISTS' value of 0x1 --- This is proving reliably inconsistent!
  • VS 2022 ALWAYS throws an exception (as expected)
  • VS 2019 ALWAYS overwrites the destination ( This is incorrect behavior of CopyFileEx )

Relevant Code:

string sourceFile = GetRandomPath();
string destFile = GetRandomPath();

Console.WriteLine(string.Format("Source: {0}\nDestination: {1}", sourceFile, destFile));
if (File.Exists(sourceFile)) File.Delete(sourceFile);
Assert.ThrowsException<FileNotFoundException>(() => FileFunctions.CopyFile(sourceFile, destFile, CopyFileExOptions.FAIL_IF_EXISTS));

File.WriteAllText(sourceFile, "Test Contents");
File.WriteAllText(destFile, "Content to replace\n\nMoreContent");
Assert.IsTrue(File.Exists(sourceFile));
Assert.IsTrue(File.Exists(destFile));

// This is the test that is inconsistent
Assert.ThrowsException<IOException>(() => FileFunctions.CopyFile(sourceFile, destFile, CopyFileExOptions.FAIL_IF_EXISTS), "\nCopy Operation Succeeded when CopyFileExOptions.FAIL_IF_EXISTS was set"); 

Other relevant code :

[Flags]
public enum CopyFileExOptions : uint
{

    NONE = 0x0,

    FAIL_IF_EXISTS = 0x1,
}

        [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Ansi, ThrowOnUnmappableChar = true)]
        [return: MarshalAs(UnmanagedType.Bool)]
        private static extern bool CopyFileEx(
            string lpExistingFileName,
            string lpNewFileName,
            CopyProgressCallback lpProgressRoutine,
            object lpData,
            ref int pbCancel,
            uint dwCopyFlags);


public static bool CopyFile(
            string source,
            string destination,
            CopyFileExOptions flags = CopyFileExOptions.NONE,
            CopyProgressCallback progressCallback = null,
            IntPtr? data = null
            )
        {
            if (!File.Exists(source)) throw new FileNotFoundException("Source File Not Found.", source);
            new FileInfo(destination).Directory.Create();
            int cancel = 0;
            bool returnVal = CopyFileEx(source, destination, progressCallback, data, ref cancel, (uint)flags);
            if (returnVal is false) Win32Error.ThrowLastError(source, destination); // Method to get last error and throw
            return returnVal;
        }

PR I discovered the issue in : tjscience/RoboSharp#193
Other files with relevant code :

• Unit Tests -- https://github.com/RFBomb/RoboSharp/blob/AsyncCopy/RoboSharp.Extensions.UnitTests/CopyFileTests.cs
• DllImport -- https://github.com/RFBomb/RoboSharp/blob/AsyncCopy/RoboSharp.Extensions/CopyFileEx/FileFunctions.CopyFileAsync.cs
• Enum -- https://github.com/RFBomb/RoboSharp/blob/AsyncCopy/RoboSharp.Extensions/CopyFileEx/CopyFileExOptions.cs
• https://github.com/RFBomb/RoboSharp/blob/AsyncCopy/RoboSharp.Extensions/CopyFileEx/FileFunctions.Callbacks.cs
• https://github.com/RFBomb/RoboSharp/blob/AsyncCopy/RoboSharp.Extensions/CopyFileEx/Win32Error.cs

Initial post for posterity : dotnet/csharplang#8046

[huoyaoyuan]

VS2019 is 32bit and VS2022 is 64bit. This should be the main difference.

The signature of 4th argument is LPVOID lpData. Using object in P/Invoke signature means the OLE VARIANT type. You should use IntPtr instead.

[RFBomb]

Alright, I am honestly at a loss here. The whole reason I had moved to try object instead of IntPtr in the call was because of it not working as expected.

I have updated the signature to :

private static extern bool CopyFileEx(
            string lpExistingFileName,
            string lpNewFileName,
            CopyProgressCallback lpProgressRoutine,
            IntPtr lpData,
            bool pbCancel,
            uint dwCopyFlags);

bool returnVal = CopyFileEx(source, destination, progressCallback, data ?? default, false, (uint)flags);

and it works in both VS 2019 and VS 2022 as expected now. Note that I also changed ref int cancel to bool cancel, but both worked, it was the lpdata part of the signature that was the issue. Its odd to me that it worked in 2022 but not 2019 as object, but apparently I had something wrong with the signature initially to cause the failure.

Anyway, its working now. Thanks for the review.

[huoyaoyuan]

Note that I also changed ref int cancel to bool cancel

This is incorrect. If you pass true, it will be interpreted as *(BOOL*)0x1 and crash.
The correct signature is ref int/in int, or ref bool/in bool with MarshalAs(UnmanagedTypes.Bool).

[RFBomb]

Thanks for the info. This is good information I wasn't able to locate elsewhere, not even in many of the articles about usage.

I had set it to ref bool pbCancel which resolved another inconsistency between compiling in 2019 / 2022. I did notice that when I specific the MarshalAs, I was then getting compiler messages to declare the strings, and wasnt sure which one use.

[huoyaoyuan]

The detailed documentation is at https://learn.microsoft.com/en-us/dotnet/standard/native-interop/type-marshalling.
For Windows API, you can also refer to https://github.com/microsoft/CsWin32 .

[RFBomb]

I will take a look into those, you've been a great help. The code generator might solve another project I'm toying with too.