.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

No of Dll Files

5 REPLIES 5
Reply
Message 1 of 6
Amremad
421 Views, 5 Replies

No of Dll Files

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

5 REPLIES 5
Message 2 of 6
architectOfIdeas
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? 

Message 3 of 6
Amremad
in reply to: architectOfIdeas

yes i know that

 

but

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

Message 4 of 6
DiningPhilosopher
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.

Message 5 of 6
dgorsman
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.
"I don't know" is the beginning of knowledge, not the end.


Message 6 of 6


@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).

 

 

 

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost