Win32-API function calls in VS2005 CLR applications

[R.Kaiser]

I know that I can call Win32 API functions in a Windows forms
application by specifying each function header individually like in

using namespace System;
using namespace System::Runtime::InteropServices;


typedef void* HWND;
[DllImport("user32.dll", CharSet = CharSet::Ansi)]
extern "C" int* MessageBox(HWND hWnd, char* pText,
char* pCaption,unsigned int uType);
void test_Win32Messagebox_1(void)
{
char* pText = "Hello World!";
char* pCaption = "Platform Invoke Sample";
MessageBox(0, pText, pCaption, 0);
}

What I want to know: Is there an easy way to include all headers by
using windows.h or a similar header file:

extern "C" {
#include <windows.h>
}

I tried to combine this #include statement with a DLLImport attribute
like from above, but I did not succeed.

Thanks
Richard

 

[David Lowndes]

What I want to know: Is there an easy way to include all headers by

using windows.h or a similar header file:

Richard,

A C++/CLI program can mix managed/unmanaged calls seamlessly - no need
for anything nasty - so if you need to interface with lots of native
code, C++/CLI is a much cleaner solution.

Dave

 

[R.Kaiser]

Hi David,

I was talking of C++/CLI applications. Can you give me an example how to
do it?

Thanks
Richard

 

[Carl Daniel [VC++ MVP]]

Hi David,

I was talking of C++/CLI applications. Can you give me an example how
to do it?

#pragma managed(push, off)
#include <windows.h>
#pragma managed(pop)

No DllImport attributes are needed. Make sure you're linking with the
appropriate import library(ies) (e.g. kernel32.lib, user32.lib, etc).

-cd

 

[R.Kaiser]

Thanks Daniel,

perhaps I confused C++/CLI and CLR applications. I need the Win32-API
functions in a CLR Windows forms application. When I proceed as you
suggested, I get numerous errors like

Carl DanieC:\Program Files\Microsoft Visual Studio
8\VC\include\vadefs.h(89) : error C3862: '__va_start':
cannot compile an unmanaged function with /clrure or /clr:safe
#pragma unmanaged is in effect

Or did I confuse something else?

Richard

 

[Carl Daniel [VC++ MVP]]

Thanks Daniel,

perhaps I confused C++/CLI and CLR applications. I need the Win32-API
functions in a CLR Windows forms application. When I proceed as you
suggested, I get numerous errors like

Carl DanieC:\Program Files\Microsoft Visual Studio
8\VC\include\vadefs.h(89) : error C3862: '__va_start':
cannot compile an unmanaged function with /clrure or /clr:safe
#pragma unmanaged is in effect

Or did I confuse something else?

You need to understand what the error message is telling you: You can't
call unmanaged functions, except via P/Invoke, in a "pure" or "safe" CLR
project. You have two choice:

1. Don't use /clrure or /clr:safe, just use /clr
2. Don't #include <windows.h> and go back to using DllImportAttribute one
import at a time.

If you take option 1, the resulting application will contain a mixture of
managed and unmanaged code and may not run in certain contexts (e.g. partial
trust environment). Winforms will work fine in a mixed-mode application -
it's entirely a function of the environment in which the application is
deployed whether this option will work for you.

If you take option 2, you're stuck with declaring the functions you need one
by one.

-cd

 

[Ben Voigt]

You need to understand what the error message is telling you: You can't
call unmanaged functions, except via P/Invoke, in a "pure" or "safe" CLR
project. You have two choice:

1. Don't use /clrure or /clr:safe, just use /clr
2. Don't #include <windows.h> and go back to using DllImportAttribute one
import at a time.

If you take option 1, the resulting application will contain a mixture of
managed and unmanaged code and may not run in certain contexts (e.g.
partial trust environment). Winforms will work fine in a mixed-mode
application - it's entirely a function of the environment in which the
application is deployed whether this option will work for you.

If you take option 2, you're stuck with declaring the functions you need
one by one.

And still won't work in partial trust... because you need native code
permission to use P/Invoke. However you'll get a runtime exception instead
of an outright failure to load.

Best of both worlds... put such calls in a separate unsafe assembly, then
you can still fail gracefully if you don't have native code permission.