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

.net helper dll's of same name, which one used?

21 REPLIES 21
SOLVED
Reply
Message 1 of 22
JamesMaeding
3137 Views, 21 Replies

.net helper dll's of same name, which one used?

I was always under the impression you could make two .net programs for acad, say called prog1 and prog2, and place supporting dll's in each of the folders.

So Prog1's folder would have "helpers.dll", as well as Prog2's folder.

Like:

  Prog1

    Helpers.dll

  Prog2

    Helpers.dll

 

Now, each prog should look to its helpers.dll, as these are not going into the GAC.

 

What I am seeing though, is my Prog2 is using the Prog1's helper.dll during debug in acad.

Note that Prog1 gets neloaded on startup, so its loaded first.

 

I had not noticed this before as I kept helpers.dll in synch. I then allowed Prog2's to get ahead, by adding a method, and noticed I got a "method missing" error at runtime in acad.

Its like VS said everything was ok, but acad somehow said "no, use this helpers.dll for the .net prog already loaded".

 

I am not netloading the helpers.dll, it just sits there as support.

Any ideas how this crosstalk could happen?

 

The implication is I would not be able to have duplicate supporting dll's for various progs I do.

That is wrong though, .net does allow dupe named dll's so long as they sit right next to the calling dll.

thx

 

 

 


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

21 REPLIES 21
Message 2 of 22
norman.yuan
in reply to: JamesMaeding

Your issue is that you expect the different DLLs with the same file name, the same version, and the same namespace, but broken compatibility (e.g. all the information in the AssemblyInfo.vb[cs] are the same) to be loaded into the same process (AutoCAD running process).

 

Your DLL is dynamically loaded when needed, Then the running process (AutoCAD) sees the need to use functionalities in a DLL, it would examine the meta data of loaded assemblies, if it has already been loaded, it will not try to load it from file again. If not loaded, it will try to loaded by looking into GAC/App folder... the usual probing.

 

So, that is why Helps.dll has already been loaded because of Prog1, then when Prog2 is loaded and needs Helps.dll, AutoCAD simply uses the loaded Helps.dll, and not tries to load Helpds.dll again from Prog2 folder.

 

The probelems is when do you deliberately create a DLL with the same filer name (and probably the same version, namespace...) yet make different interface (properties, methods) in it? At least you need to make different versions (.NET allows the same components with different version being loaded side by side), if you have to keep the DLL name, namespace the same for some reasons.

 

 

 

Message 3 of 22
JamesMaeding
in reply to: norman.yuan

I see, very well explained.

Things like versions have never mattered to me since I generally recompile all programs if my central library changes.

Its always "the latest" 🙂

 

I will try that right now. Dealing with making sure no other .net progs of mine were loaded into the debug session was not easy (or fun)....

thanks a bunch!


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

Message 4 of 22

Nicely explained Norman. Kudos to you.

 

James - I suggest you mark that as your accepted solution.

 

Cheers,

Stephen Preston
Autodesk Developer Network
Message 5 of 22

I was going to mark it as solution, and think it is the right answer, but its not working.

I opened the solution for prog1, and edited all the Assemblyinfo.cs files to have:

[assembly: AssemblyVersion("1.0.*")]

//[assembly: AssemblyFileVersion("1.0.0.0")]

 

I commented the file version so it would use the AssyVersion, and I could see in props of file in windows explorer.

 

I purposefully commented out a particular method I know prog 2 needed before I compiled.

I then compiled, and placed the new files in my regular prog1 folder which is where acad finds them.

It seemed to assign the version info as expected. I verified in explorer.

 

I then uncommented the method and ran prog2 under debug, and got the method missing error.

I looked at the details to see what dlls were loaded, and it only lists the one from Prog1.

See Pic of one acad listed, and details of one from prog2 folder. The versions are different, but acad never loaded the one from prog2.

Asm Vers.jpg

 

 

That HAH General CS.dll is the helper function that is different between prog1 and prog2.

Did I misunderstand something? I thought the different versioning would make acad load both and use the one prog2 is calling for.

thanks

 


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

Message 6 of 22
JamesMaeding
in reply to: JamesMaeding

just thought of something. Does acad maybe only look at major version (3rd number) of an assy to decide if its the right one?


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

Message 7 of 22
jeff
in reply to: JamesMaeding

The attributes window explorer show are just for public information Product, File, version etc....

 

The one that matters is AssemblyVersion but unfortunately AutoCAD does not allow strongly named assemblies which is required for the CLR to look at the AssemblVersion.

 

I have no idea if this would in this situation but if you want reference the assembly of different versions in the same project..

 

Select reference then in the Properties palette change alias from global to oldversion or whatever 

Then in code file  instead of a using directive use

extern alias oldversion;

 I have no idea if it will work in this situation but that is one way to load multiple versions of same assembly from different locations into same project.

 

 

 

You can also find your answers @ TheSwamp
Message 8 of 22
norman.yuan
in reply to: JamesMaeding

In my previous reply, I mentioned versioning. At the time I just vaguely recall .NET allows different versions of a component lives side by side from my early experience with .NET and had not touched this topics for years. Then I went to a bit study and test last night and here what I can say:

 

If you want to load the same component with the same assembly file name, namespaces..., but different version, into the same running process (AutoCAD, or other), the assembly has top be strongly signed and installed into GAC.

 

I did a test as following:

 

1. create 2 class library projects that has the same output DLL file name, the same namespaces, only differ with their assembly versions (1.0.0.0, and 1.1.0.0). Both projects have a static method doing different things: Add() and Substract().

 

2. Strongly signed the 2 projects and compile them;

 

3. Add the 2 DLLs (the file names are the same: "myLib.dll") to GAC with gacutil.exe tool;

 

4. Create a 2 Acad Addin projects. One of them references to myLib.dll v1.0.0, the other references to MyLib.dll 1.1.0. Note, I needed to point the reference to correct MyLib.dll file, because the MyLib.dll added into GAC does nt show up in "references" dislog box (unless I update the windows registry, which I do not bother). "Copy local" to MyLib.dll should be set to False, but even leaving it to True does not do hurt, because 2 versions of MyLib.dll in the GAC, and any app using them will always try to load them from GAC first anyway.

 

5. One Acad Addin has a command method ("Test1") that calls Add() in MyLib.dll v1.0.0, the other Acad addin has a command method ("Test2") that calls Substract() in MyLib.dll v1.1.0. Compile each projecys.

 

6. Start AutoCAD, net load AcadAddin1 and then netload AcadAddin2. execute command "Test1" and Test2". both work as expected: one does the adding and the other does the substracting, obviously from the 2 MyLib.dll versions being loaded into the same AutoCAD process.

 

Of couse I tried to load the 2 version of MyLib.dll into AutoCAD before strongly signed them and adding them to GAC. It did not work.

 

If we think it through, it make sense for not strongly signed DLL, the file name determines whether the assembly has been loaded or not, because it is physically stored in file system and can be overwitten by the any file with the same file name, regardless its version, content. While GAC is a special storage for .NET assembly that allows different versions of assembly stay side by side (but must be strongly signed).

 

So, if you really have to use the same assembly file name with different versions for particular reason, you have to strongly sign them and place them into GAC. which requires admin priviledge to get it done on each computer that may use your application. It may not worth the trouble doing it.

Message 9 of 22
JamesMaeding
in reply to: norman.yuan

wow, I think the whole ADN team should give you kudos on that research.

I would guess experienced .net people know you must use the GAC, but its not mentioned much in this forum.

Very much appreciated.

 

You are correct that I do not want to have to "install" my prog1 and 2 with admin.

I support about 60 cad users and update their tools via xcopy methods (robocopy.exe actually).

So I will have to figure out how I do things.

I will likely recompile both progs should I make any library changes.

If I am doing that, I might as well throw both progs in same folder too, no point in keeping separate.

 

I sure wish really really badly there was a way to do the GAC stuff via script, even if it meant exposing my login password.

I do not have security problems, I have timing problems.

I need to be able to tell users via an email to close acad's when convenient, then run some batch to update their tools.

As is, for admin requiring items, I have to have them close acad's, then run a special script through our remote admin prog from my desk. It interrupts what I am doing.

So solving that would pave the way for using GAC, I know its the right way to do it really.

thx

 


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

Message 10 of 22
jeff
in reply to: JamesMaeding

Public deploy - GAC(Shared among different applications)

Privatley deployed - Placed in directory or sub-directory of application.

 

It just has to be Strongly named for the CLR to lokk at version number.

You can add Probing paths, Redirective bindings, etc.. inside app.config file(acad.exe.config)-Privately deployed.

 

You can avoid the GAC but would have to be strongly named and inside of autocad installtion folder.

 

 

This might be more of a project structure-maintenece problem instead of trying to load 2 different versions.

 

 

You can also find your answers @ TheSwamp
Message 11 of 22
JamesMaeding
in reply to: jeff

win 7 does not allow non-admin to touch prog files folder, so not an option.

 

I'm actually not super inconvenienced by this issue. I can recompile all progs and throw together in one folder.

That may change fast though, so this instruction is invaluable.


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

Message 12 of 22
chickenkon
in reply to: jeff

Message 13 of 22
jeff
in reply to: chickenkon

Hi Norman,

 

Out of curiousity what did your functions Add and Substract do?

The reason I ask is I do not see how it would of worked, but that is with the assumption of trying use types defined in the autocad assemblies.

 

In my first post I mentioned AutoCAD does NOT allow strongly named assemblies, but should of said strongly named assemblies can only reference or use types from other strongly named assemblies.

 

 

Did the MyLib.dll have any references to autocad assemblies?

If so is 2014 autocad assemblies now strongly named?

 

 

 

 

 

 

 

You can also find your answers @ TheSwamp
Message 14 of 22
norman.yuan
in reply to: jeff

Hi Jeff,

 

I did not/forgot to mention that the 2 strongly signed DLLs (with the same file name and namespace in them, but different methods and different versions) that worked in the same AutoCAD process after being added into GAC) do not include AutoCAD opersions (e.g. do not have references to AutoCAD's managed API assemblies).

 

Yes, you are correct, since AutoCAD's .NET API assemblies cannot be strongly signed, so, if one want to strongly sign his own DLL, the DLL cannot reference AutoCAD .NET API assemblies (or any other assembly that is ot strongly sign-able). So, to your question: the 2 methods - Add() and Substract() - in the 2 same-named DLLs iin just a simple adding and substracting, no other DLLs (AutoCAD .NET assemblies) are referenced. That was meant for just making a point that side-by-side version existence requires strongly signed assenblies. I did not bother to try, but supposed that you are correct that after strongly signed, the 2 DLLs can be loaed into the same process (AutoCAD) without having to ne added into GAC.

 

This brings to this question to the OP: why one needs to deliberately have 2 assembly DLLs with the same file name but dufferent content in them while it almost certain that can be avoided?

Message 15 of 22
jeff
in reply to: norman.yuan

Thanks for all the info was just checking I did not misunderstand something.

 

 

P.S.

Enjoy reading your blog, thanks.

You can also find your answers @ TheSwamp
Message 16 of 22
JamesMaeding
in reply to: norman.yuan

in reply to " question to the OP: why one needs to deliberately have 2 assembly DLLs with the same file name but dufferent content in them while it almost certain that can be avoided?"

 

Once I realized the acad environment only allows one of each non-strongly named dll to be loaded, I did switch to mushing together my progs in one folder, and just making sure each worked correctly.

I essentially have a set of tools that works with just autocad, then one that works on Civil3D also.

I tend to work on one or the other for weeks, but not both.

So when one gets ahead of the other, I need them separate.

 

I dealt with the same thing with lisp and compiling to vlx. Its always nice to the helper libraries compiled in, or at least sitting right next to a main program.

Turns out Bricscad does not yet support separate namespaces with lisp, so its the same deal where you must keep all progs up to date with helper library changes.

 

Having said all this, I would say the hardest part about .net is project/solution organization. It seems obvious to career programmers that work in groups, but cad managers like me that work alone, have to get advice as they run into it. No one looks over my shoulder and says "you could just do this". So threads like this are golden to me. Hopefully I will work in an experienced group someday, but my main skill is creating workflows for civil engineering and acad tasks. My company does not sell tools so its not the focus. They do appreciate the ones I do, and we are replacing Civil3D for most users with better tools than adesk writes. Its fun, but challenging to constantly improve on my .net library and processes. I'd rather be making my 3D printer 🙂


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

Message 17 of 22
jeff
in reply to: JamesMaeding

You maybe think of a solution as a tool to take projects and create assemblies from them and can have different build configurations.

 

For me the easiest way to create one for a class library is to use Empty Solution Template. Andchange settings like where bin folder for release is located, etc......

Would copy libriares you reference into libs folder so it easy for source control and can use from any computer and not have to worry about drive names etc...

 

Your Civil tools would reference the the AutoCAD Tools dll in bin folder so it will get updated version when built, but anytime AutoCAD tools is updated would need to rebuild civil tools in this type structure.

The src folder is where you put your solution.

 

Kinda quick and not a good explanation but will would have to explain better later.

 

 

Looking at pic below  did some copying of existing folder and edited it.

 

DevProjs      - Is top folder level

 --.git  - SourceControl Folder at this level

 --Autodesk  - Can think of this name as client

   --Autocad

      --bin

         --v19

      --libs

         --v19

            --acdbMgd.dll

            --accoremgd.dll

      --src

         --MeadingAcadTools - Solution Folder

            --SolutionFile          

   --Civil

      --bin

         --v19

      --libs

         --v19

            --acdbMgd.dll

            --accoremgd.dll

            --civilMgd.dll

      --src

         --MeadingCivilTools

            --SolutionFile          

   --MEP

 

Project.PNG

 

You can also find your answers @ TheSwamp
Message 18 of 22
JamesMaeding
in reply to: jeff

hmm, not sure what you mean on the acad dll's as you must set copylocal to false and always use ones in acad install folder I thought.

 

Right now, I have a folder for each library, and the libraries are split by function and what references are needed.

csSoln.jpg

 

I don't use subfolders a lot in my projects.

The biggest thing was figuring out how to make things that worked for different acad and bricscad versions. I use conditional compilation symbols for that now.

I'm still wondering if its necessary to split the projects like I did.

If I use the HAH Forms CS, which has a system.windows.forms reference, in a console app, would that work or freak on that reference?

Do most places split libraries at the project level or just by code level (.cs files) and dump in one big project?

 


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

Message 19 of 22
jeff
in reply to: JamesMaeding

I will get a screen shot of project folder tomorrow.

 

You are correct and that you still set copy local to false for acad.dll's but have ever downliaded a sample and had to update path to acad's dll.?

 

This keeps all its 3rd party, etc.... references realative to the solution it will take up more space on your disk from multiple copies but makes it easier to use with source control and from other computers

 

    <Reference Include="AcCoreMgd">
      <HintPath>..\..\..\..\libs\Acad\v19.0\AcCoreMgd.dll</HintPath>
      <Private>False</Private>
    </Reference>
    <Reference Include="AcDbMgd">
      <HintPath>..\..\..\..\libs\Acad\v19.0\AcDbMgd.dll</HintPath>
      <Private>False</Private>
    </Reference>

 

You can also find your answers @ TheSwamp
Message 20 of 22
JamesMaeding
in reply to: jeff

not following, those paths do not point to acad install folder.

Is there a way to run things on acad dll's not in install folder?


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