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

assembly's by the same name

6 REPLIES 6
Reply
Message 1 of 7
JamesMaeding
317 Views, 6 Replies

assembly's by the same name

If I have two programs which each have a required dll named "AcadHelper.dll", and each prog is in a separate folder, will this cause problems?

I have read on this a lot, but wanted to check that I understand this right.

Each program will use the dll's needed that lie in the same folder as the main dll, right?

 

I am not registering anything with the GAC, I want xcopy install ability.

thx


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

6 REPLIES 6
Message 2 of 7

If both AcadHelper files are the same, it should not cause a problem.  But just to be clear, if you load both programs into the same session, the first one will load the AcadHelper.dll from the same directory, then the second one will use the AcadHelper that is already loaded.  (I believe it will attempt to load the .dll from the same directory, then fail to do so because it creates duplicate entries, but because the entries are duplicates, the program will work using the references already loaded).

 

I am not exactly sure what would happen if the two files are completely different.  (ie. they do not contain any of the same functions).  I think that would also work, but if they contain some of the same functions, and some different functions, you will have problems when loading both programs into the same session.

Dave O.                                                                  Sig-Logos32.png
Message 3 of 7

and that would be dll hell.

I thought .net did not do that, as its not looking to windows to find the object definitions for some class, unless registered in the GAC.

I thought the only way you could get into dll hell with .net was by unthoughtful use of the GAC.

Can anyone else comment on this? One of us is incorrect for sure....


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

Message 4 of 7

Another way to put what I am saying is "just because an assembly is loaded into acad, does not change how it finds other assemblies", right?

 

Do the helper assemeblies get "netloaded" when used. I thought they did not.

I could test by defining commands in the helper assembly, and see if those are available even though I did not netload it.

thx


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

Message 5 of 7

"Do the helper assemeblies get "netloaded" when used."

 

I believe that is exactly what happens.  I have a similar situation to what you are describing, with a CadTools.dll that is referenced by all my other CAD related programs.  My CadTools.dll does have some commands defined in it, as they are useful commands no matter which of the programs you happen to be using.  (You can even load the CadTools.dll by itself, and just use those commands, without loading any of the other assemblies that reference it)

 

As soon as any of my primary programs is Netloaded (all automatically under various circumstances), the CadTools commands are available even though I do not have it set up for demand loading.

 

There is one other developer here at my company, and his CAD program references the same .dll.  We used to merge our assemblies together (so that the tools .dll became a part of the primary .dll) but quickly found that meant we could not load both of our programs together because they contained duplicate definitions of everything in the CadTools.

 

Judging by your comment, I assume you have some of the same and some different functions in each Helper?  Why not just make one helper .dll and reference the same one in both primary .dll's?

 

Or - you could pull all of the duplicate functions out into a Main Helper, referenced into both projects, and put the code that is different into (either the primary .dll where they are needed, or a seperate Sub Helper .dll)  Honestly, if it does not make sense to combine your Helpers into one, then it seems to me that it would make sense that the functions that are different, really belong in the Primary .dll.

 

 

Dave O.                                                                  Sig-Logos32.png
Message 6 of 7

your suggestion to reference the helper dll to both is what I would do, in an ideal world.

What can happen though, is I change stuff in the helper, then recompile and post new helper and program A.

Program B is expecting the helper without the "enhancements" and glitches.

 

I recall the GAC is made for this issue of same name assemblies.

So lets say I was wreckless in my helper dll changes and always wanted progs a and b to work.

 

What distribution method should I use?

I will read up and post what i find, as its a basic topic in the average book. I was just looking for real world experience opinions in addition.

thx


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

Message 7 of 7
JamesMaeding
in reply to: JamesMaeding

from what I read, assemblies are private, as long as in the same folder as the main prog.

So I plan to have a folder for prog a, and another for prog b.

if I do that, the helper dll in each can be different.

 

Its the whole netload thing that could change things, so thx for feedback so far.


internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties

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