Managing External Dlls–Make Your Project Portable and Independent
I think that any programmer have tackled with this problem of missing dlls , or suddenly the dlls are upgraded in the server and you are left with your application to pick up the pieces.
SO , how can we handle the dlls so that our application won’t be effected by almost anything?
First of all , it is important to understand that the solution presented here does not cancel the need to install the Framework on the destination machine, meaning that the correct framework must be there always in order for your application to work properly.
There are few solutions for managing your dlls :
1)Reference to GAC as usual
2)Add a folder to specific project with your needed dlls
3)Add a solution folder to your solution and locate your needed dlls there
4)Locate your dlls on some Shared Folder in your organization
5)Build a new Project and insert the dlls there
In each and every solutions there are Pros and Cons as always :
| method | pros | cons |
| 1)Reference to GAC as usual | You don’t need to worry about anything, it’s all in the system. If you are using standard Microsoft dlls , even if there will be an upgrade of the dlls version , Microsoft always tries to make it backward compatible – it won’t touch you. | If you have some specific dlls , such as Oracle.DataAccess.dll etc. then it can happen that the dll that you have on your terminal , that you develop with is a different version – in this case when you publish your application on the server your application won’t work properly. You’ll get mistakes of bad assembly reference or one of it dependencies. |
| 2)Add a folder to specific project | It’s easy, and whenever you deploy the project you are carrying your dlls with you. | If you have a few projects in your solution you can’t use it properly between the projects. You need to keep the location of the folder specific.You could reference the dlls for your current project from a different project folder but when you’ll take the current project as a reference to some third component and then one of the dlls change – you’ll need to recompile all components. |
| 3)Add a solution folder to your solution and locate your needed dlls there | It’s a logical unit just holding the dlls – you are adding a logic meaning composing the dlls by logical themes. | When you work with TFS or VSS or any source safe you need to have a physical object of a folder. Another thing – if you have a lot of dlls and you need to drag and drop a whole folder of them into solution folder – you CAN’T, so you’ll have to create every folder by hand inside that solution folder and then import dlls files , folder by folder. |
| 4)Locate your dlls on some Shared Folder in your organization | That’s one of the “good” solutions if you work in organization with LAN , and ability to control permission over domains . You just throw the dlls to some folder and share it with every one you like. If there are multiple users on the same dll , the system creates copies and you won’t get stacked. | The down side is handling the source safe again . It creates decentralization of your application. Another thing , in terms of maintenance you can always forget the specific location of the shared folder or not get enough permissions after system team will perform some update on the server. |
| 5)Build a new Project and insert the dlls there | SO, the great solution yet is to add a new Class Library project , drag and drop the folders you need to take with you and recompile. Any component in your solution will reference the autonomic defined component . You can manage it under your source safe and you can enter it in your deployment package – leaving the hierarchy as predefined at the begging. If the dlls change – all you’ll need to do is to throw the External Dlls project to the server. |
When you create the project and drag and drop the folders you’ll get “Project file must include the .NET Framework assembly ‘WindowsBase, PresentationCore, PresentationFramework’ in the reference list.” error . It means that your dlls are defined as a Content . You need to go through the folders , choose the dlls(can choose list of them) and in properties change the Build Action to Resource. That’s it. |
So , in this review I’ve shown the best way to make your project portable and independent.
Now you can enjoy the deployment. Cheers!
