External DLL and Database Driver

Question

I want to create a Windows Form that refer to - let say - crud.dll. Then I want the crud.dll be as an external dll. The idea is, the crud.dll(which connect to database) will have many versions (eg. Sybase version, SQLite version, different version for different database details). For my case, the crud.dll is using Sybase.Data.AseClient; When I build, I got error because Sybase.AdoNet2.AseClient.dll also depends on another dll. How to do things the right way? Thank you for your time.

you then also need to put the other dll in the same folder so that it can be found by its dependent. — Moriya, Jan 28 '13 at 07:36
I'm using Win 7. When the error occur, two alert boxes pop up. One with title "Microsoft .NET Framework" and very descriptive message, the other one with title "my app name" and two option: 1) Check online for a solution, 2) Close the program. The problem is, this later box prevent me from seeing the more descriptive box. How to get rid of the second box? — Iyas, Jan 28 '13 at 07:44

score 1 · Answer 1 · edited May 23 '17 at 12:12

1

You need to abstract the database access code from you application logic. You may use Repository pattern in conjunction with Dependency Injection to isolate your database operations from your application logic.

edited May 23 '17 at 12:12

Community

1
1

answered Jan 28 '13 at 07:37

daryal

14,643
4
38
54

score 0 · Answer 2 · answered Jan 28 '13 at 07:43

What you want requires you to compile separate Windows Form applications for each DLL, since the application will statically link the referenced DLL. Clearly not a desirable approach. An alternative would be use dynamic loading (LoadLibrary, GetProcAddress), but that is error-prone and the difficulties in locating the right crud.dll leads to DLL-Hell.

A better alternative is to statically type all supported providers in the application (eg. the typical repository pattern implementation would fall into this category) which eliminates all these problems, but the set of supported providers will be hard-wired at application compile time.

The modern alternative would be to expose the services provided by crud.dll via COM and have the application configure the desired COM class (which is backed by one of the providers implementations).

Ultimately loading a provider * dynamically* and not having the list of supported providers statically fixed at build time is hard. I would seriously revisit the requirements and consider whether having a well known set of supported providers be fixed at compile time, and use one of the many statically linked approaches available (eg repository pattern).

External DLL and Database Driver

2 Answers2