views:

224

answers:

3

My dll have been bigger multiplied up many times than early for some reason. I'm beginning to size up the situation:

  1. A source hasn't changed.
  2. Debug information everywhere turned off.
  3. Dll use package "Pack", but not include in Runtime Packages options.
  4. I've compared new dll with old version dll thought the instrumentality of PE Explore. In new dll I find out many modules with prefix 'ec' implicitly imported unlike old dll.
  5. Package "Pack" using ecControls components
  6. Dll doesn't using explicitly call to ecControls units.

Why ecControls units imported in dll? Have anybody some advice?

+1  A: 

If your DLL is using a package that's not included in the Runtime Packages list, then its units will be implicitly imported into your DLL instead of linking to the runtime package. That's probably what's causing it right there. Try adding the package to your Runtime Packages list and see if the ecControls issue goes away.

Mason Wheeler
+2  A: 

If a unit in ecControls is accidentally used, it's initialization section (if it has one) will be called and you can put a breakpoint in there to try and see where it is being called from. You can also put a breakpoint in System.InitUnits (with debug dcus on) to see if any unit in ecControls is being initialized.

I use this technique in Forms.pas when working on a dll to make sure that Forms.pas is not being linked in accidentally.

Alan Clark
Awesome tip. The Initialization section is often overlooked, and I never thought about leveraging it that way.
Chris Thornton
+1  A: 

Why you dont just rename the ecControls directory and rebuild (deleting the package first of course)? That will let you see exactly where it is being referenced.

sjdngkjsdgjsdn