I'm writing a simple console app which uses EDSDK (13.16.00) and I'm struggling with trying to overcome a STREAM_BAD_OPTION error response to an EdsCreateFileStreamEx call in the callback triggered by a 'TakePicture' command. I've used the DLLs before in a Java/JNA app with no problem. I'd originally used the 'non-extended' version of the DLL call (EdsCreateFileStream) before realising that C# uses Unicode strings rather than ANSI strings, but changing to the extended (Unicode friendly) has made no difference. The other command parameters seem trivial enough not to be a problem. I've tried with both the 64bit and the 32bit version of the EDSDK. Same result. I've built and run some other sample code (EDSDKLib) which seem to do pretty much the same as my code and that runs without error. So I'm really now looking for advise about how to pin down (and fix) the cause of the STREAM_BAD_OPTION error.

The relevant call declaration is are:

[DllImport(DllPath, CharSet = CharSet.Unicode)]
public extern static ErrorCode EdsCreateFileStreamEx(string inFileName, FileCreateDisposition inCreateDisposition, FileAccess inDesiredAccess, out IntPtr outStream);

and is used as:

String inFileName = outDirItemInfo.FileName;
IntPtr outStream;
EdsCreateFileStreamEx(inFileName, FileCreateDisposition.CreateAlways, FileAccess.ReadWrite, out outStream);

What an I missing? Every other DLL call up to this point has completed successfully and there doesn't seem to anything particularly tricky in the EdsCreateFileStreamEx call (once I'd spotted the Unicode/ANSI issue).

[Edit] The native side of the failing method is declared as:

EdsError EDSAPI EdsCreateFileStreamEx(
    #if defined __MACOS__ || TARGET_OS_IPHONE
        const CFURLRef              inURL,
    #elif defined TARGET_MOBILE
        const char                  *inFileName,
    #else
        const WCHAR*                inFileName,
    #endif
       EdsFileCreateDisposition     inCreateDisposition,
       EdsAccess                    inDesiredAccess,
       EdsStreamRef*                outStream );

Also I've managed to "make the error go away" (as opposed to "fixed") by changing the stream access to write-only instead of read-write. No idea why this should make a difference - I (and others) have use read-write streams here successfully before.