Special DLL for applications to use

Question

5.00/5 (2 votes)

See more:

I have a question regarding Dlls. I am working on C programming and using visual studio. All codes (both Dlls and applications) are in C.

Assume I have a DLL version 1.0, and I like to specify this version being used by my application A, also DLL Version 2.0 will be for Application B. And probably DLL Version 3.0 can be linked to both applications A and B. Is there a way to prevent incorrectly link?

The reason is that I have different version of dlls or some dlls built for testing purpose only. I like to put something either in a configuration file or inside dll (may be some resource file) to stop accidentally linking of wrong dlls.

Any idea will be appreciated!

Added follow up clarification from OP below:

First of all, many thanks to both answers!
I think I may need to make the question a bit specific: I actually want to stop the compiling/linking process if the incorrect version of DLL is used.
Here is process I normally face:
One or a few people will build a DLL (or a few). These DLLs will be passed to another group (application engineers) for building the final application (GUI changes for example). Sometimes, the people will forget which version of DLL is for a particular application. This is true when multiple similar features are added/enhanced.
Since functions in DLL and in application are defined in header file and almost always with same prototype, it is very easy to mix the things together. What I initially thought was there might be some ways to put a list of "allowed" application versions in a given DLLs as well as some configuration file (or even header file). I don't think I want to completely stop someone to build or use DLL if he knows what he is doing. But a warning message during compiling/linking is probably good.
All these things are just to improve the internal development process. I don't mean this idea for end-user as we should have installed correct code for our final product.
Any suggestion?

Posted 28-Mar-11 14:11pm

Member 2182617

Updated 29-Mar-11 15:27pm

HimanshuJoshi

v3

Add a Solution

Comments

Sergey Alexandrovich Kryukov 28-Mar-11 20:13pm

This is a serious question, my 5.
--SA

HimanshuJoshi 29-Mar-11 21:28pm

Edited to move follow up clarification in the question itself.

Albert Holguin 30-Mar-11 20:07pm

First of all, if you have an update this big (where the solutions went completely in a different direction)... you should probably comment on our solutions, otherwise we don't get a notification.. anyway, if you're going to stop compilation/linking, it has to be done through pre-processor directives and macros.

3 solutions

Solution 2

Check out the Microsoft Side-by-side technology
http://msdn.microsoft.com/en-us/library/aa376307(VS.85).aspx[^]
http://msdn.microsoft.com/en-us/library/aa375155(VS.85).aspx[^]

From the MSDN:
"Developers are encouraged to use side-by-side assemblies to create isolated applications, and to update existing applications into isolated applications for the following reasons:
* Side-by-side assemblies reduce the possibility of DLL version conflicts.
* Side-by-side assembly sharing enables multiple versions of COM or Windows assemblies to run at the same time.
* Applications and administrators can update assembly configuration on either a global or per-application configuration basis after deployment. For example, an application can be updated to use a side-by-side assembly that includes an update without having to reinstall the application."

Might be what you're looking for.

Posted 28-Mar-11 19:27pm

hansen303

Solution 4

With your updated question, use combination of pre-processor directives to achieve this:

within your DLL:

#define DLL_VER2

within your application (your DLL must be set as a dependency at this point, that'll make it compile first):

#ifndef DLL_VER2
#error The current application requires DLL_VER2 for compatibility.
#endif

Of course, make sure that your error statements will make sense to the other developers.

Posted 30-Mar-11 14:19pm

Albert Holguin

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Albert Holguin · Accepted Answer · 2011-03-28T14:28:00

Solution 1

Only way I can think of is to have some sort of difference in the DLLs (I'm assuming dynamic linking):
1) Different version called out in the DLL name (that can be addressed uniquely on LoadLibrary).
2) At least one (or more) unique function calls to differentiate by searching export functions after LoadLibrary.
3) Have one of your exported functions (or imported depending on point of view) be a call to request the version number, you should be able to call it early in app before trying to use it in any way).

Posted 28-Mar-11 14:28pm

Albert Holguin

Comments

Hans Dietrich 28-Mar-11 21:25pm

Correct. #3 is the one I usually use. My 5.

[no name] 29-Mar-11 2:33am

If it is versions of one dll, then there should be the same interfaces.

Albert Holguin 29-Mar-11 9:46am

Actually that's not true... there's nothing that says the interface should be exactly the same...

Example: You build a DB.dll interface that networks your application to a remote DB, it gets released with version 1 and App A. After it gets released, you find out that you probably need more broad function calls because your calls are generating too much network traffic. To solve the problem, you create broad calls in DB.dll version 2, App A can still access what it needs if the original functions are all there, but the new functions in DB.dll version 2 are accessible to App B (called App A, Enterprise Edition). Two versions of the same DLL, one has additional functions.

As you can see, no reason to have the same exact functions, there's really nothing that says the calls HAVE to be exactly the same. That's up to your application's and DLL's interface specification.

HimanshuJoshi 29-Mar-11 21:23pm

My 5 specially for #3; that would be best in the said situation.