.NET

Reply
Mentor
Amremad
Posts: 217
Registered: ‎08-24-2010
Message 1 of 6 (252 Views)

No of Dll Files

252 Views, 5 Replies
05-08-2013 12:02 AM

Is there a problem in separating my Code to more than one Dll File

 

Ex:

Dll For Printing and it's action

Dll For Logs file

Dll For Fitting

Dll for other work

 

or the best  make all this operations in one dll file

Valued Contributor
architectOfIdeas
Posts: 75
Registered: ‎08-10-2007
Message 2 of 6 (227 Views)

Re: No of Dll Files

05-08-2013 08:55 AM in reply to: Amremad

i believe this depends on a couple things.

 

what's prompting you to split the procedures up into separate .dll files?

are you finding the code to be unmanageable in one .dll file?

are you looking to re-use the .dll files by multiple plug-ins? 

Mentor
Amremad
Posts: 217
Registered: ‎08-24-2010
Message 3 of 6 (199 Views)

Re: No of Dll Files

05-09-2013 01:44 AM in reply to: architectOfIdeas

yes i know that

 

but

is the largest number of dll may make any debuge in autocad??

Valued Mentor
DiningPhilosopher
Posts: 370
Registered: ‎05-06-2012
Message 4 of 6 (179 Views)

Re: No of Dll Files

05-09-2013 11:27 PM in reply to: Amremad

Splitting applications into multiple DLLs has a slight performance overhead, but unless all of the DLLs are very large, it isn't really noticable.

 

If you have several applications that share a common code base, then it makes sense to put the shared common code into a seperate assembly so that each application that uses it does not have to replicate the code.

*Expert Elite*
dgorsman
Posts: 5,698
Registered: ‎10-12-2006
Message 5 of 6 (164 Views)

Re: No of Dll Files

05-10-2013 11:28 AM in reply to: Amremad

Logical splitting may make sense if everything isn't needed right away, or at all during some sessions, in which case demand-loading can be implemented.  E.g. if you had a custom batch plot as part of a larger drawing manager application it might make more sense to split it out and load it when called for instead of every time.  It can also make for easier debugging and updates if there isn't a lot of reliance on each other.  Multiple files require a little more management in making sure they get loaded, copied, updated etc. as opposed to a single file where its either done or not.

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
Adopt. Adapt. Overcome. Or be overcome.
A good question will be halfway to a good answer.


Valued Mentor
DiningPhilosopher
Posts: 370
Registered: ‎05-06-2012
Message 6 of 6 (151 Views)

Re: No of Dll Files

05-11-2013 11:33 PM in reply to: dgorsman

dgorsman wrote:

Logical splitting may make sense if everything isn't needed right away, or at all during some sessions, in which case demand-loading can be implemented.  E.g. if you had a custom batch plot as part of a larger drawing manager application it might make more sense to split it out and load it when called for instead of every time. 

 


Splitting an assembly up into multiple assemblies for the reason you cite above, serves no purpose, and is pointless.

 

In a just-in-time compiled execution environment, every method in an assembly is "demand-loaded".  Or, put more simply, the runtime does not load and compile methods and their code unless and until they are actually used. If a method is never called in a session, it is never loaded or compiled (this doesn't apply to assemblies that are pre-compiled using ngen.exe).

 

So, in fact, there really is no purpose served by splitting an assembly up because parts of it may never be needed in a session, so that each of the component parts can be 'demand-loaded', because every method in an assembly is already being demand-loaded. In fact, breaking up assemblies for that purpose alone can partially-defeat the purpose of just-in-time compilation, because each assembly has a fixed amount of overhead, regardless of its size.

 

Most of the legitimate reasons that determine how a code base is laid out, have to do with dependencies on other code or libraries that may not always be present (e.g., RealDwg has no AcMgd.dll), or because the developer is following best practices and maintaining separation between various functional layers (e.g, separating UI from business logic).

 

 

 

Post to the Community

Have questions about Autodesk products? Ask the community.

New Post
Announcements
Do you have 60 seconds to spare? The Autodesk Community Team is revamping our site ranking system and we want your feedback! Please click here to launch the 5 question survey. As always your input is greatly appreciated.