Click here to Skip to main content
14,033,409 members
Rate this:
Please Sign up or sign in to vote.
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?
Updated 29-Mar-11 15:27pm
Sergey Alexandrovich Kryukov 28-Mar-11 20:13pm
This is a serious question, my 5.
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.
Rate this: bad
Please Sign up or sign in to vote.

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).
Hans Dietrich 28-Mar-11 21:25pm
Correct. #3 is the one I usually use. My 5.
Kozlov_Sergey 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.
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

Check out the Microsoft Side-by-side technology[^][^]

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.
Rate this: bad
Please Sign up or sign in to vote.

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.

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

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

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Cookies | Terms of Service
Web05 | 2.8.190423.1 | Last Updated 30 Mar 2011
Copyright © CodeProject, 1999-2019
All Rights Reserved.
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100