C++/CLI Mixed Mode does not allow FILE struct?

Question

I have an old Visual Studio C++ 6.0 DLL that I am trying to get call in a managed C++/CLI Code.

Here are the project settings that I used:

1. Add the additional header directory for the unmanaged code
2. Add the additional library directory for the unmanaged code
3. Specify the lib file name of the unmanaged code
4. Set the CLR option to /clr
5. Removed the precompile header
6. I am using VS2012 so I tried to lower the tooling to VS2008 \ I had just added the main header of the unmanaged code in the managed C++/CLI code.

The problem is it keeps on getting C2143 error in the struct definition.

The code is as follows

// logs struct
typedef struct FilesLog {
    FILE    *fpSender ;                   // <- Error in this line
    FILE    *fpReceiver ;                 // <- Error in this line
    int SendCount , ReceiveCount ;
} FilesLog_t ;

It gets C2143 on FILE lines also in another FILE line inside a class definition. (which means the error is not just on structs)

I have tried mixing and matching the project settings but it still does not work. Any ideas?

Here is the whole token error as suggested in the comment. Based on my understanding this means it does not recognize FILE that is why it is saying it needs a semicolon before *.

 error C2143: syntax error : missing ';' before '*'

Answer 1

Quite apart from the compiler errors you are getting, what you are attempting will never work.

FILE* is associated with internal data structures of the C++ runtime. The DLL will only accept FILE* values from its own Visual C++ 6.0 runtime, think of that as a FILEVC6MD*. If you use fopen in the C++/CLI DLL, you get a FILE* from the Visual C++ version it is compiled with, which you should think of as FILEVC9MD* (when compiling with Visual Studio 2008 tooling). It is a completely different data type. They aren't compatible in the slightest.

Generally having FILE* in the public API of a DLL is a very bad idea. Using your existing Visual C++ 6.0 DLL can only be done if it compiled with /MD to use a shared DLL for the runtime library, and then only by a caller using the same runtime library, which means either Visual C++ 6.0, or mingw. That rules out C++/CLI.

Your only hope for consuming this DLL from .NET is to write a wrapper compiled in Visual C++ 6.0 that exposes a saner public interface. That wrapper DLL can be called from p/invoke or C++/CLI.