I'm one of the crazy people who has worked with C++/CLR to make native C++ code coexist with .Net code. It runs really well, with a minimum of frustration.
Except for one thing. We rely on some components supplied by a third party. These components have both Debug and Release versions. You'll notice that the References are listed under "Common Properties" in the Properties window, so you can't create separate references for Debug and Release by simply switching to the appropriate property set.
This has been annoying me now for at least two years, and I finally found a solution, thanks Marco Beninca in this post:
http://social.msdn.microsoft.com/Forums/en-US/clr/thread/9087fb4f-149f-4d66-b33e-f2f280c65fa6
The solution is to use #using in your source code instead of defining your assembly references on the "Framework and References" page. Then you can go to the General page for C/C++ and set different directories for Debug and for Release.
The other advantage to this solution is that you don't have to reset all of your references when you get a new version of the components.
One disadvantage to this strategy is that the compiler no longer takes care of copying the appropriate DLLs to the appropriate directories. This can easily cause you to build with a different set of DLLs than you are running against, which will certainly cause a crash. My solution was to create a Pre-Link step that copies the DLLs to $(OutDir).
Hey Jim,
ReplyDeleteI had a question for you since you seem extremely knowledgeable and I am just a novice who can't seem to find an answer to this anywhere...here goes...
a requirement was sent to me below:
API should be in the form of static library. company xxx will link the library into a third party application to prevent any possible exposure of the code(dll)
could they mean an import library? An import library is a library that automates the process of loading and using a dynamic library. On Windows, this is typically done via a small static library (.lib) of the same name as the dynamic library (.dll). The static library is linked into the program at compile time, and then the functionality of the dynamic library can effectively be used as if it were a static library.
this might be what they might be eluding to.....I am not sure how to make this in vs2008 .
Additional facts: I have a static lib that i use in my current application. Now, I have to convert my app that uses that static lib into an import lib so that they can use a third party prog to access the API's they providede me which in turn will use that static lib i am using.
I hope I am clearly explaining this. I am just not sure how to go about it in vs2008. I am looking for specific steps to do this. I already have the coding done. Just need to convert it into the form they are asking and I have to provide the API they want. Other than that then I need to create a test prog which will act as that third party prog so I can make sure my import library works.
Khurram,
ReplyDeleteGoogle is your friend. I searched for "visual studio static library" and came up with several good results, including:
http://www.functionx.com/visualc/libraries/staticlib.htm
http://msdn.microsoft.com/en-us/library/ms235627(VS.80).aspx
thanks for your response. But do you think from that requirement they want a dll import that can be used as a static lib which basically changes the whole ball game? since an import library can use a dll as a small static lib?
ReplyDeleteIt appears from their requirement that a DLL is not acceptable, so therefore an import library is not acceptable.
ReplyDeleteYou need a standalone static library.