Help Needed : Error using a DLL after compiling with /CLR

I'm trying to take an old(er) C Win32 app and move towards managed C++ (C++/CLI).

I have successfully made the modifications to the code to bring it up to C++ specs. I will compile/link and run just fine as C++.

I can compile it as C++ code, but when I make the move to managed (via the /CLR) compiler switch I have *one* problem.

The program uses many dll's.. some written in house some 3rd party. All the inhouse and most of the 3rd party dll's work fine, but I can not get a Crystal Reports dll to work. (Crystal Reports 5.0)

Specifically when the code calls PEOpenEngine() I receive an error(512). This error just tells me that the "Print Engine" did not load.

I'm planning on moving to a newer version of crystal, or something else, but I would really like to get the app compiling as managed asap.

Thank you,
JF

Answer this question

Help Needed : Error using a DLL after compiling with /CLR

DanieLondon
I don't think its that I have all the nessassary DLL's in the build target directory. If I have the project set for native C++ it compiles/links/runs. If I enable the /CLR switch it compiles/links and will run just fine except for that one call.

I can call *other* crystal reports functions, But I can not get it functioning. Its very old, and I guess my question should have been "How do I find out what is causing a DLL to stop functioning when I move from native to /CLR for a C++ program "
Chimme2
I appreciate the advise, I will try that first thing monday morning.
Naive
It is fairly unlikely that this problem has anything to do with your port to the CLR, PEOpenEngine doesn't take a lot of arguments. This looks more like a specific problem with Crystal Reports, such as not being able to find a DLL it needs to setup the print job. Try using the Profile option in Dependency Walker to see if anything jumps out.
Gentia
I'd still try a profile with Dependency Walker. Since you have a working version, you can easily compare that trace with the one that doesn't work. They won't match at startup since the CLR libraries get loaded in the non-working version. It should start to get interesting after you see it loading CRPE32.dll, the Crystal Reports DLL that contains PEOpenEngine(). Better yet, try to trigger the call off a button and clear the trace window just before you click the button.
Ksa_Java

OLE v.2.0 COM seek platform independence, not ony language independence. The .NET Franework, however, should be studied irregardless becuase it is an architectural model. It just so happens to be the infrastructure for the .NET platform. Well-written documentation wil define shared assemblies as those not private to a client application. They must be registered in the Global Assembly Cache, so the kernel will know what exactly what it is and what to expect. Once registered in the GAC, they now serve as system components, a sysztem DLL that any process can use. One might view it as an .exe file, but there is no stack frame, message queuing, and so on.

In order to register the assembly ( which is a DLL or component) in the GAC, a public/private key pair must first be generated as a random key pair in an output file. the shared name (sn.exe) can do this,

so the DLL is built with both version number and key information based on that output file. Know

the difficulty with compiler using the /CLR switch has to indicate that something is out the common language runtime, and there is type library to interface beween managed and unmanaged code.

Aszsume the output file from the sn.exe utility is identfier.key. sn -k identier.key. The k swithc generates the random key pair and saves it the output file. Know we have the orignal source of the DLL,

RootOut.cpp: we compile using the .NET Framework cl /CLR /c RootOut.cpp

Now we link: link -dll /out:RootOut.dll RootOut.obj

This has built an assembly n the form of a DLL, yet has avoided the registration process required by COM: gacutil.exe /i RootOut.dll

Now resigistered in the GAC, it is know by the kernel as a DLL that any client can use. One of the single most important libraries to know in .NET is mscorlib.dll. With that mind, we avoid any linker name collision by a namespace. Guess what Having built an assembly we use ildasm.exe to disamble it to obtain metadata. The system api Reflection API is able to inspect and emit that metadata. This has a relation to the services in transactions in COM+, like object pooling, security, data marshalling, etc. this is called attribute based programming . The attribute sort of serves as an organizatinal unit in COM+ services and transactions. Like a pipe used RPC, an attribute has both an [ in ] and [ out ] attribute that dscribes the pulling or pushing of the data from or to server.

These information from having examined the .NET Framework often clarifies the resons for compiler error.
IngeW
I looked at the output from dependancy walker this morning. I didn't see anything around the use of the crpe32.dll that differed from each.

Just to be sure I started a new project, the only thing it does is a LoadLibrary on the crpe32.dll and then tries the PEOpenEngine() call.

same results, all calls from the crpe32.dll are line for line (Native vs. /CLR)

I know the DLL is loading because I can execute other functions (like the get version functions).
Help Needed : Error using a DLL after compiling with /CLR

Answer this question