By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,289 Members | 1,342 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,289 IT Pros & Developers. It's quick & easy.

Compile C source in mixed-mode projects

P: n/a
DFB
I am the author of the ZLibNetWrapper project on SourceForge (located
at zlibnetwrapper.sf.net). This project is a simple mixed-mode .NET
wrapper around the ZLib compression library. The ZLib code consists of
a few C source files.

For Visual Studio 2003, this wrapper compiled fine without having to
change any of the ZLib source. However, according to "Breaking Changes
in the Visual C++ 2005 Compiler" (at
http://msdn2.microsoft.com/en-us/lib...s177253.aspx):

/clr no longer compiles C source code files

Prior to Visual C++ 2005, you could compile C source code files with
/clr,
however this will now result in Command-Line Error D8045. To resolve,
change the file extension to .cpp or .cxx, or compile with /TP or /Tp.

So it appears that this technique to wrap the ZLib source will no longer work
due to changes in Visual Studio 2005, unless you can compile the C source
as C++ rather than C. Unfortunately, the project won't compile this way.

Are there any compile options or other techniques to make this project
compile under VS2005?

The only other options seem to be:

a) Modify the ZLib source so that it compiles as C++ code.

b) Separate the ZLib code into an independent DLL that the mixed-mode
wrapper calls.

c) Just keep using the .NET 1.1 version of the DLL.

Is this a correct assessment?
-Dave
Jul 14 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
a) Modify the ZLib source so that it compiles as C++ code.
>
b) Separate the ZLib code into an independent DLL that the mixed-mode
wrapper calls.

c) Just keep using the .NET 1.1 version of the DLL.
I do have not read the ZLib code, but most of the time, when C code does not
compile as C++ code, it is because of type mismatching.
If at all possible, I would try to make it compile as C++ code. It should
not be that hard.

b) introduces extra work. If you are going to do work anyway, you might as
well go for solution a)
c) would work for now, but is not future proof. apps cannot mix different
versions of the .NET framework.
programmers would not be able to use your component with .NET 2.0 or higher
since VS2003 can only compile for 1.1.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"
Jul 14 '06 #2

P: n/a
Bruno van Dooren wrote:
b) introduces extra work. If you are going to do work anyway, you might as
well go for solution
ZLib already comes as an unmanaged DLL, though. Sometimes I use the DLL
version, and sometimes I link it to the project statically. But it takes
0 time to create that DLL -- it already exists.

I would not modify the ZLib code (other than trivial-to-fix conflicts in
the header file). It's a very stable, open source library. Once I
thought of rewriting it in C++, but it would be a tremendous amount of
work, I would lose connectivity with the original library, I would lose
stability and access to the security patches. So instead, I just wrapped
it into a C++ class, instead of rewriting it.

So my recommendation is to download the DLL version of ZLib, and try to
call it from a mixed-mode project. I have many unmanaged DLLs that I'm
using from mixed-mode code, and ZLib is one of them.

Although I haven't used ZLib directly from C++/CLI, I'm using an
unmanaged DLL of mine that uses the ZLib DLL internally, and I have
absolutely no problem using this from C++/CLI:

[C++/CLI mixed-mode app] ---[unmanaged DLL] ---[original ZLib DLL]

Tom
Jul 14 '06 #3

P: n/a
DFB
So my recommendation is to download the DLL version of ZLib, and try to
call it from a mixed-mode project. I have many unmanaged DLLs that I'm
using from mixed-mode code, and ZLib is one of them.
Yes, I assumed that this would be the simplest way to go since it should not
be any problem to call the ZLib DLL from the mixed-mode DLL. Deployment
requires two DLLs, though.

I wonder, however, if the limitation on C code in CLR mixed-mode DLLs could
be worked around by statically linking to a library containing the ZLib
source, rather than compiling the C directly into the DLL. I haven't tried
this yet.

Any insight about this technique?

Thanks,
-Dave

Jul 14 '06 #4

P: n/a
DFB wrote:
I wonder, however, if the limitation on C code in CLR mixed-mode DLLs could
be worked around by statically linking to a library containing the ZLib
source, rather than compiling the C directly into the DLL. I haven't tried
this yet.
I haven't tried that, but that should work too. I think it's worth a
try. Just be sure to switch the compiler to unmanaged mode for the
entire zlib header file:

// mixed-mode project including zlib.h:
#pragma unmanaged
#include "zlib.h"
#pragma managed

Also use VC++ 2005 to produce the zlib.lib file, not another compiler.
Other than the /clr option, the rest of the compiler options should
match (same data alignment, use multi-threaded dynamic RTL, and so on).

Tom
Jul 14 '06 #5

P: n/a
>b) introduces extra work. If you are going to do work anyway, you might
>as well go for solution

ZLib already comes as an unmanaged DLL, though. Sometimes I use the DLL
version, and sometimes I link it to the project statically. But it takes 0
time to create that DLL -- it already exists.
Ah. Not knowing ZLib, I didn't know that.
In that case, option B could have been described better as 'use the existing
ZLib dll in a mixed mode .NET wrapper'.
With that in mind, your suggestion is better.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"
Jul 14 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.