 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / July 2006Compile C source in mixed-mode projects
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/library/ms177253.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 > 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.  SignatureKind regards, Bruno van Dooren bruno_nos_pam_van_dooren@hotmail.com Remove only "_nos_pam" > 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 > 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 > 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 >> 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. SignatureKind regards, Bruno van Dooren bruno_nos_pam_van_dooren@hotmail.com Remove only "_nos_pam" Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.