VC unmanaged/managed issues for c# programmer

[Dan Diephouse]

I am attempting to write a DLL which wraps C# code. The issue at hand is
a print driver allows you to extend it by writing a DLL. Seeing that
VC++ seems to be hopelessly out of my mental reach, I thought I'd write
the DLL in C#. Of course, it turns out I can't solely write the DLL in
C# managed code. I have to create an unmanaged wrapper. So I have the
following stub below which I need to fill in. I've gotten to the point
where it compiles, but I get this warning:

Linking...
Creating library .\Debug/softcopyex.lib and object
..\Debug/softcopyex.exp
LINK : warning LNK4243: DLL containing objects compiled with /clr is not
linked with /NOENTRY; image may not run correctly

Which evidentally means that I cannot write a DLL which calls managed code?

If you're interested, the docs for the dll are here:
http://www.dobysoft.com/products/sof.../overview.html

I apologize for the patheticness of this question because I'm so
ignorant of vc++, but I'd appreciate pointers anyone can give me.

- Dan

#using <mscorlib.dll>

#include <vcclr.h>
#include <windows.h>
#include "softcopy.h"
#include <string.h>

using namespace System;

#pragma unmanaged
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID
lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

// Return job characteristics
BOOL WINAPI scGetJobInfo(SCJOBINFO* info)
{
lstrcpy(info->formName, L"Letter");
info->printQuality = 300;
info->colorType = SC_OUTPUT_COLOR;
info->jpegQuality = 90;
info->tiffCompression = SC_TIFTYPE_JPEG;
info->tiffQuality = 90;
info->pdfQuality = 90;
return TRUE;
}

// Return output filename and image type.
BOOL WINAPI scGetSaveFileName(SCFILEINFO* info)
{
// TODO call C# method here
return FALSE;
}

// Display end-of-job message box
void WINAPI scEndOfJob()
{
return;
}

[William DePalo [MVP VC++]]

"Dan Diephouse" <da*@envoisolutions.com> wrote in message
news:wq********************@comcast.com...

I am attempting to write a DLL which wraps C# code.
OK.
The issue at hand is a print driver allows you to extend it by writing a
DLL. Seeing that VC++ seems to be hopelessly out of my mental reach, I
thought I'd write the DLL in C#.
Hmm. How much work do you need to do in the DLL? You may end up going where
no man has gone before (using .Net/CLR in the print driver extension) in
order not to write the DLL in C / C++.
Of course, it turns out I can't solely write the DLL in C# managed code. I
have to create an unmanaged wrapper.
Right.
Linking...
Creating library .\Debug/softcopyex.lib and object
.\Debug/softcopyex.exp
LINK : warning LNK4243: DLL containing objects compiled with /clr is not
linked with /NOENTRY; image may not run correctly

Which evidentally means that I cannot write a DLL which calls managed
code?

No, it doesn't mean that, just that there are "issues". :-)

First, the expedient way to "solve" your problem is to choose Properties on
the Project menu, then click on the Linker "folder" icon so that it is open.
Select Command Line under the Linker folder and in the edit box labeled
Addition Options on the right pane add

/NOENTRY

That tells the linker that you don't want to link the usual startup code
into your DLL. Why this is necessary is a long story <g>. (I think that the
story gets better with Whidbey).

This may or may not be all you need to do. For the details, you will want to
read this:

http://support.microsoft.com/?id=814472

and post again if the build fails.

Regards,
Will

[Dan Diephouse]

William DePalo [MVP VC++] wrote:

"Dan Diephouse" <da*@envoisolutions.com> wrote in message
news:wq********************@comcast.com...

I am attempting to write a DLL which wraps C# code.

OK.

The issue at hand is a print driver allows you to extend it by writing a
DLL. Seeing that VC++ seems to be hopelessly out of my mental reach, I
thought I'd write the DLL in C#.

Hmm. How much work do you need to do in the DLL? You may end up going where
no man has gone before (using .Net/CLR in the print driver extension) in
order not to write the DLL in C / C++.

A fair ammount. We need to have a dialog which needs to pop up, we need
to do some web service stuff (i.e. send the file generated to our server
via soap).

Of course, it turns out I can't solely write the DLL in C# managed code. I
have to create an unmanaged wrapper.

Right.

Linking...
Creating library .\Debug/softcopyex.lib and object
.\Debug/softcopyex.exp
LINK : warning LNK4243: DLL containing objects compiled with /clr is not
linked with /NOENTRY; image may not run correctly

Which evidentally means that I cannot write a DLL which calls managed
code?

No, it doesn't mean that, just that there are "issues". :-)

Hahah.. I just love "issues" :-).
First, the expedient way to "solve" your problem is to choose Properties on
the Project menu, then click on the Linker "folder" icon so that it is open.
Select Command Line under the Linker folder and in the edit box labeled
Addition Options on the right pane add

/NOENTRY

That tells the linker that you don't want to link the usual startup code
into your DLL. Why this is necessary is a long story <g>. (I think that the
story gets better with Whidbey).

This may or may not be all you need to do. For the details, you will want to
read this:

http://support.microsoft.com/?id=814472

and post again if the build fails.

OK, I took a peak at that document, and didn't think it would be that
simple. (Of course I'm prone to not read it because it doesn't render
right in firefox - are listening microsoft???)
Adding "/NOENTRY" gives me:
Creating library .\Debug/softcopyex.lib and object
..\Debug/softcopyex.exp
LIBCMTD.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
referenced in function _mainCRTStartup
..\Debug/softcopyex.dll : fatal error LNK1120: 1 unresolved externals

Looking at the support doc, I followed the commands to manually
initialize the statics variables. I can get that to compile - but I
don't think it'll work because it says I need to change the consumer as
well, which I don't have control over.

Maybe it would be better to just exceute a C# program via the command
line argument with some arguments?

- Dan

[William DePalo [MVP VC++]]

"Dan Diephouse" <da*@envoisolutions.com> wrote in message
news:ts********************@comcast.com...

OK, I took a peak at that document, and didn't think it would be that
simple.
It would be nice if mixed mode applications were easy. They are not. More
than a peek may be required.
(Of course I'm prone to not read it because it doesn't render right in
firefox - are listening microsoft???)

Well, I don't want to sound like an apologist for them, but their developer
site (MSDN) is literally HUGE, it contains a wealth of information and in
fact the answer to your dilemna. I'd go looking for the blue E icon about
now. <g>

So, are you planning to use C++ in the native DLL? What about C++
exceptions?

If one of the answers is no, then just for giggles, right click on the
source file(s) in the Solution Explorer, select Properties, then under the
C++ folder icon select "Code Generation". In the right pane try setting
"Enable C++ exceptions" to No. Now rebuild.

Does the build error go away? If not, as Emily Litella used to say -
nevermind.

In any case, error or not, you'll need to read the article. You must insure
that no non-trivial things happen at the time the DLL is loaded. The article
goes on to explain how to initialize the run time and static variables
safely, but after the fact.

Someone may pop in here and offer info on whether the loader-lock problem
goes away with Whidbey (VS 2005). If so, depending on your release schedule,
you might want to download it

http://lab.msdn.microsoft.com/vs2005/

Regards,
Will

[Andrea Sansottera]

William DePalo [MVP VC++] wrote:

"Dan Diephouse" <da*@envoisolutions.com> wrote in message
news:ts********************@comcast.com...

OK, I took a peak at that document, and didn't think it would be that
simple.

It would be nice if mixed mode applications were easy. They are not. More
than a peek may be required.

I'm playing right now with the C++/CLI compiler beta whose definitive
version will ship with Whidbey.

I think that everything will be much easier than now...

I really like the new syntax and the possibility to compile
native/mixed/pure/safe code. I've read a few articles, and even if I've
never used Managed-Extensions-For-C++ I got writing mixed code that
worked in a few minutes. Obviously there is no a real-world problem
which is so easy to solve, but I went a bit further than the traditional
"hello world".

Most important, if you have a C++ backend, it is not hard at all to well
understand the way the compiler and the CLR will work with your code. I
had that sensation of power and control over the machine that only
native C/C++ gave me in the past.

What I'm saying: there is really cool stuff that will ship with Whidbey,
I'm going to stay tuned... and think to forget C# :)

--
Andrea Sansottera
UGIdotNET [Italian] http://www.ugidotnet.org
My weblog [Italian] http://blogs.ugidotnet.org/andrew/