?
Solved

To create a DLL or not to create a DLL?

Posted on 2003-02-24
15
Medium Priority
?
265 Views
Last Modified: 2010-05-03
I'm in a quandry over whether to spend time setting up a common dll file for my program package. I thought using DLL's as "Best Pratice" or "Best of Breed".  The following statement found elsewere in the forum started me to thinking about this.

"If you don't want to register DLLs, don't use them. Nothing says you have to.  Make sure there are specific reasons you are creating DLLs.  Mainly speed or to apply a 3-tier architecture especially if your DLL is going to reside on the server and is separating the UI from direct access to the data source.  Also creating a DLL is not the same as a COM object.  COM objects (that just happen to be compiled to DLL) have specific entry and exit points as well as using interfaces.  There is a lot more to creating COM than just compiling a DLL."

My requirements are to:
- Provide access to about 50 functions from various programs
- Run no more than 4 of the programs at the same time
- Keep task sizes under 500K (This can be done w/o Dll)
- Make the programs understandable when I look at them a year from now
- Speed is not a problem
- Following program best practices. (Sometimes we have too many choices ... and sometimes not)

Could someone comment on whether I need to bother with creating a DLL or not?


0
Comment
Question by:gdwright
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 6
  • 2
  • +1
15 Comments
 
LVL 28

Expert Comment

by:AzraSound
ID: 8011430
Generally speaking, to me, a DLL is a good idea if it means it will aid you in extensibility and maintainability.  You say you have some 50 functions that various programs will need access to.  If you don't encapsulate this into a DLL, you will find yourself duplicating this same code for each program.  This means:

1) You're doing some copying/pasting
2) Anytime you need to change something in any one of those functions, you have to change it everywhere
3) Anytime you add a function somewhere, you have to add it everywhere else


If you use a DLL, instead you:

1) Have a single entity holding the logic
2) Only require to update the function at one place
3) You only add a function in one place



This makes developing less of a headache in the future should any conditions arise that make updating functions a common task.  If you do go that route, and I assume you are referring to COM DLLs, brush up on compatibility issues so you understand what happens, and what is required, should you need to make changes to your DLL and still allow programs referencing it to function properly.
0
 
LVL 1

Expert Comment

by:jeffreyhamby
ID: 8011496
My two cents...

There are other reason's to use .DLL's as well.  One reason I use them is to "hide" the functionality from the Junior Developers and keep from confusing them (or keep the functions from being changed unless they really need it).  Another is to wrap functionality for webpages, since I hate HTML mixed with code, and try to keep it to a minimum.

I'm not really sure if these fit anyone elses best practices (other than my colleagues, who do the same) but they work well in my situation.  

Most, still, are for distributing the application load, and seperating business logic from data logic, however.  My main goal is to make the code easy to understand for the next developer who's going to have to look at this code.
0
 

Author Comment

by:gdwright
ID: 8013488
AzraSound, in VB you can put the code in a module and attach it to the project. This eliminates the need to duplicate it.

jeffreyhamby, you have me thinking. Are there occasions when you just leave the common functions in a module?
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 28

Expert Comment

by:AzraSound
ID: 8013877
>>AzraSound, in VB you can put the code in a module and attach it to the project. This eliminates the need to duplicate it

Granted, you can have a single module in some location, and then all projects referencing the module at that single location.  I don't store my modules that way...I'll make a copy of it and put it in the project path I am working on.  However, despite that method, it still means recompiling each project after the change is made.  With a DLL, you have a single compile, and all projects are updated.
0
 

Author Comment

by:gdwright
ID: 8014374
AzraSound, you make a lot of sense. But how about debugging. Once I go to a Dll, I loose the ability of inline debugging using the IDE. Doesn't this make it more difficult, if not impossible, to track down and fix runtime errors?
0
 
LVL 8

Expert Comment

by:drydenhogg
ID: 8015414
You dont have to loose debugging ability when the functionality is within a DLL.
Create a project group containing the project that is using the dll, and the dll project itself.

Change the references so that the executable project references the vbp of the dll and not the compiled dll, VB will then use the copy you have loaded in the group allowing all the normal breakpoints, step in, over etc.

The older method before project groups was to have 2 copies of VB in memory one with the DLL loaded and running, the other with the project, was messy but did allow debugging.

ADH.
0
 
LVL 28

Expert Comment

by:AzraSound
ID: 8016706
You can create a project group as suggested by drydenhogg, but I actually prefer the second method he mentions, even though his preference is otherwise.  If you have your DLL project open, go to Project -> Properties, select the Debugging tab, and ensure "Wait for components to be created" is selected.  Then, you can click the Run button and your DLL will be in "run" mode and you can set breakpoints, etc.  Now, open ANY project you have that references that DLL, run it, and once you call any method of the DLL, you can see it calling it via a breakpoint in the open DLL project.  You are, essentially, debugging both at the same time, and it doesn't require that you create a project group for every project that references the DLL in which you wish to debug.
0
 
LVL 8

Expert Comment

by:drydenhogg
ID: 8016831
Aye, azra's right in that I prefer the group method, I changed due to the ability to get yourself caught out in a 'Switch To...' loop from stopping things in the wrong order when not concentrating.

ADH.
0
 

Author Comment

by:gdwright
ID: 8018043
I hope forum admin has a way of giving out points to mutiple good comments. We'll work on that shortly. I now really, really want to use a dll but have one last hurdle. What to do about my variables that are shared between the calling program and the dll. Maybe I'll have to do some rewriting and pass them as arguments. But I sure would like to create a single pool that is shared by everyone. Is this possible?
0
 
LVL 28

Expert Comment

by:AzraSound
ID: 8018101
Do you mean that you want a single copy of your DLL in memory and that multiple executables may be launched that use the DLL, and you want them all to use this single instance (thus, sharing the variables of the DLL)?
0
 

Author Comment

by:gdwright
ID: 8018312
Yes!
0
 
LVL 28

Accepted Solution

by:
AzraSound earned 300 total points
ID: 8018487
Ok, well, remember that a DLL runs in-process, that is, it runs within the process space of the application calling it.  Thus, you won't be able to share anything with other applications running in processes because, generally speaking, for security reasons, you cannot read/write to another processes memory space.

However, an ActiveX EXE does run in its own process space, and following the conventions of COM, it can be treated as an object just like an ActiveX DLL.  It's still not as straightforward as we would like it to be, though, to use a "shared" instance of this ActiveX EXE (because VB does not, by default, register ActiveX EXEs into the ROT).  It is possible however, and I found a sample application that should give you all the code necessary to approach the task in this manner, if you so choose:

http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=12319&lngWId=1
0
 

Author Comment

by:gdwright
ID: 8018578
Let me back up and say Yes and No. I only want the DLL and a SINGLE .EXE to share the variables. I tried using an object pointer to the DLL and found that the .EXE is being assigned  its own copy of the varibles. All of the shared variables are also defined in a multiuser DLL by the way. I'll look at you example. Maybe it will shed some light.
0
 
LVL 28

Expert Comment

by:AzraSound
ID: 8018868
I'm not sure what you mean, then, yet.  Perhaps a small snippet of code from the DLL and the EXE to give me an idea...
0
 

Author Comment

by:gdwright
ID: 8165366
I've deceided not to use a DLL or ActiveX DLL this time around. I'll wait until I convert my project to C# and maybe design it around a DLL.

Thanks for your help
Greg Wright
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I’ve seen a number of people looking for examples of how to access web services from VB6.  I’ve been using a test harness I built in VB6 (using many resources I found online) that I use for small projects to work out how to communicate with web serv…
This article describes some techniques which will make your VBA or Visual Basic Classic code easier to understand and maintain, whether by you, your replacement, or another Experts-Exchange expert.
Get people started with the process of using Access VBA to control Excel using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Excel. Using automation, an Access application can laun…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…
Suggested Courses
Course of the Month9 days, 21 hours left to enroll

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question