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

assembly missmatch

12 REPLIES 12
Reply
Message 1 of 13
Anonymous
473 Views, 12 Replies

assembly missmatch

If I load my managed code into AutoCAD 2005 using netload I get this
message, "The located assembly's manifest definition with name 'acdbmgd'
does not match the assembly reference".

Checked versions and they are different, development machine has 16.1.84.0
where the client machine has 16.1.63.0, so I see why I get the message.

So tried copying development machines acdbmge.dll and acmgd.dll into working
directory of my working dll. no joy, So tried copying over dll on client
machine no joy and kills layer dialog, So if .net is a way out of DLL hell
is it just changing the name to Assembly Hell

Anyway any ideas to fix the problem without reinstalling all the 2005
AutoCAD's from the same CD used on the development PC.

Before I posted I decided to try copying the client Dlls and reference them
in the project and compile, this appears to do the trick as the clients are
the older, also works on the development debug so this appears to be the
answer.

I would think for commercial apps this could be a nightmare so what is the
correct fix for this if any.


Laurence
12 REPLIES 12
Message 2 of 13
cgay
in reply to: Anonymous

Laurence,

I think that what you have found is by design. As far as a commercial app, the developer would typically create an installer that checks to see if the machine meets certain requirements before allowing the new code to be installed. So the copy method of deployment fails in this instance. You wouldn't expect code you have written for Acad2006 to run in 2005 would you? What you are attempting to do is very close to the same thing. An older 2005 version probably shouldn't and doesn't work with code that expects 16.1.84.0 or greater of the acdbmgd library.

My advice is to either design for the lowest common denominator (16.1.63.0) or ensure that your installation program won't let it install on a machine that doesn't meet the minimum requirements ( >=AutoCAD 2005 16.1.84.0).

C
Message 3 of 13
Anonymous
in reply to: Anonymous

Thanks, and comments noted and all very valid.

I think what I am trying to say is that I have not come across any
documentation from Autodesk that there are different versions of these
required mgd dlls. So if I where developing for commercial use I would not
have come across the problem unless I tested on a client with a lesser
version of the dll.

I think the problem is because me version of AutoCAD 2005 came from the ADN
download and the client are obviously commercial products. Maybe that all
commercial CD's have the same version (or maybe a UK / USA thing) but if
this was the case why is the ADN download a newer version, anyway I am just
speculating, just hope there are no lower versions than 16.1.63.0 in my
company.

Laurence

wrote in message news:5078583@discussion.autodesk.com...
Laurence,

I think that what you have found is by design. As far as a commercial app,
the developer would typically create an installer that checks to see if the
machine meets certain requirements before allowing the new code to be
installed. So the copy method of deployment fails in this instance. You
wouldn't expect code you have written for Acad2006 to run in 2005 would you?
What you are attempting to do is very close to the same thing. An older 2005
version probably shouldn't and doesn't work with code that expects 16.1.84.0
or greater of the acdbmgd library.

My advice is to either design for the lowest common denominator (16.1.63.0)
or ensure that your installation program won't let it install on a machine
that doesn't meet the minimum requirements ( >=AutoCAD 2005 16.1.84.0).

C
Message 4 of 13
Anonymous
in reply to: Anonymous

wrote

>> I think that what you have found is by design.

I don't see how that can be possible. If there are
multiple versions of ac*mgd.dll floating around, I
would regard that as a serious problem.

The reason is, because there can only be one of
them loaded into AutoCAD, so if a given user has
two or more applications that are dependent on
different versions of these dlls that are not fully
interchangable, then quite obviously there is a
deadlock, and a major problem.

I would consider it highly irresponsible, if Autodesk
were allowing this to happen.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

As far as a commercial app, the developer would typically create an installer that checks to see if the machine meets certain requirements before allowing the new code to be installed. So the copy method of deployment fails in this instance. You wouldn't expect code you have written for Acad2006 to run in 2005 would you? What you are attempting to do is very close to the same thing. An older 2005 version probably shouldn't and doesn't work with code that expects 16.1.84.0 or greater of the acdbmgd library.

My advice is to either design for the lowest common denominator (16.1.63.0) or ensure that your installation program won't let it install on a machine that doesn't meet the minimum requirements ( >=AutoCAD 2005 16.1.84.0).

C
Message 5 of 13
Anonymous
in reply to: Anonymous

Try copying all these files:

acmgd.dll
acdbmgd.dll
acdbmgdhost.dll

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Laurence Skoropinski" wrote in message news:5078385@discussion.autodesk.com...
If I load my managed code into AutoCAD 2005 using netload I get this
message, "The located assembly's manifest definition with name 'acdbmgd'
does not match the assembly reference".

Checked versions and they are different, development machine has 16.1.84.0
where the client machine has 16.1.63.0, so I see why I get the message.

So tried copying development machines acdbmge.dll and acmgd.dll into working
directory of my working dll. no joy, So tried copying over dll on client
machine no joy and kills layer dialog, So if .net is a way out of DLL hell
is it just changing the name to Assembly Hell

Anyway any ideas to fix the problem without reinstalling all the 2005
AutoCAD's from the same CD used on the development PC.

Before I posted I decided to try copying the client Dlls and reference them
in the project and compile, this appears to do the trick as the clients are
the older, also works on the development debug so this appears to be the
answer.

I would think for commercial apps this could be a nightmare so what is the
correct fix for this if any.


Laurence
Message 6 of 13
Anonymous
in reply to: Anonymous

I copied the clients acmgd.dll and acdbmgd.dll to the development PC and
removed the c:\program files\Autocad 2005 versions references and then
referenced the copied dll's. This appears to work, as application works on
client and development PC's.

I think your point is what I was trying to say in a roundabout way. I wonder
if it is a USA/UK issue as I assume the ADN download will be USA CD image.


"Tony Tanzillo" wrote in message
news:5079164@discussion.autodesk.com...
Try copying all these files:

acmgd.dll
acdbmgd.dll
acdbmgdhost.dll

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Laurence Skoropinski" wrote in message
news:5078385@discussion.autodesk.com...
If I load my managed code into AutoCAD 2005 using netload I get this
message, "The located assembly's manifest definition with name 'acdbmgd'
does not match the assembly reference".

Checked versions and they are different, development machine has 16.1.84.0
where the client machine has 16.1.63.0, so I see why I get the message.

So tried copying development machines acdbmge.dll and acmgd.dll into working
directory of my working dll. no joy, So tried copying over dll on client
machine no joy and kills layer dialog, So if .net is a way out of DLL hell
is it just changing the name to Assembly Hell

Anyway any ideas to fix the problem without reinstalling all the 2005
AutoCAD's from the same CD used on the development PC.

Before I posted I decided to try copying the client Dlls and reference them
in the project and compile, this appears to do the trick as the clients are
the older, also works on the development debug so this appears to be the
answer.

I would think for commercial apps this could be a nightmare so what is the
correct fix for this if any.


Laurence
Message 7 of 13
cgay
in reply to: Anonymous

Tony,

Not quite sure I follow. It seems to me that the client machine in question with the 16.1.63.0 version just doesn't have the correct service pack installed. And the versions available in the SDK are from a newer service pack ( SP1). I wouldn't expect this situation to work completely in any case. Now I could be totally wrong in this case, but on my machine, my AutoCAD 2005 has the 16.1.84.0 versions and the About box says (AutoCAD 2005 - English SP 1). Now I expect code written for SP1 to be forward compatible (i.e. if there ever was a SP2 for Acad2005), but not backward compatible. So this is a by design behavior, is it not?

C
Message 8 of 13
Anonymous
in reply to: Anonymous

Your are correct the client does not have a service pack and the development
does. Hmmm service packs, didn't think of that and it is so obvious.

Laurence

wrote in message news:5079390@discussion.autodesk.com...
Tony,

Not quite sure I follow. It seems to me that the client machine in question
with the 16.1.63.0 version just doesn't have the correct service pack
installed. And the versions available in the SDK are from a newer service
pack ( SP1). I wouldn't expect this situation to work completely in any
case. Now I could be totally wrong in this case, but on my machine, my
AutoCAD 2005 has the 16.1.84.0 versions and the About box says (AutoCAD
2005 - English SP 1). Now I expect code written for SP1 to be forward
compatible (i.e. if there ever was a SP2 for Acad2005), but not backward
compatible. So this is a by design behavior, is it not?

C
Message 9 of 13
Anonymous
in reply to: Anonymous

wrote

>> Now I expect code written for SP1 to be forward
>> compatible (i.e. if there ever was a SP2 for Acad2005),
>> but not backward compatible. So this is a by design
>> behavior, is it not?

I certainly hope not!

Can you cite any other case where a customer application
written in any API (LISP, VBA/ActiveX, or native ObjectARX)
was broken and completely disabled, as a result of doing
nothing more than installing a service pack (or not installing
a service pack that the application was developed with) ?

Are you nuts?


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com
Message 10 of 13
cgay
in reply to: Anonymous

Tony,

I am saying that most code IS forward compatible. Like I said, I WOULD expect code I written for AutoCAD Pre SP1 to work Post SP1 and possibly beyond (although there are many documented cases in MS Windows where this is not always the case.)

Even AutoCAD acknowledges that backwards compatibility may not work, which is why it (backwards compatibility) is not supported.
See "API and Script Compatibility" here:
http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=2935303

As far as LISP is concerned, I admit that I have no experience with versioning of it, but I expect that if AutoCAD 2005 LISP defines a function that AutoCAD 2004 LISP doesn't define, my LISP code will not work with AutoCAD 2004.

As far as VBA is concerned, If I program for a newer interface for say IAcadUtility2, which doesn't exist in Acad2004, this code will not even run, erroring out with an unknown type. And have those of you with both 2005 and 2006 installed ever noticed that the newer (2006) type libraries are always used in VBA?

Unfortunately, I can not comment on ARX, that is not my area of expertise. But if I expect a function exported from any exe or dll to exist and it doesn't, this will stop a program from running.

MS COM in general has had many problems with this very scenario (google DLLHELL). A program installs an older dll to the system, which may break a program expecting a newer version of said dll (could even prevent the system from running altogether, BSOD in the worst cases).

.NET is supposed to prevent many of these problems, but AutoCAD is dependant on specific versions of DLLs to run properly, most of which are written in ARX which have their own dependancies.

As an example of where NOT installing a required service pack breaks functionality, see the beginning of this thread.

If Laurence does install SP1 for AutoCAD 2005 on the Client, his code should then run. I am sure he will let us know if this is not the case.

C
Message 11 of 13
Anonymous
in reply to: Anonymous

You seem to be making the mistake of confusing
major releases, and service packs.

Please consider using a little common sense, to
understand why 'backward/forward compatibility'
in the context used in the document you posted
a link to, as well as most other contexts, applies
to major releases, BUT NOT service packs.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:5080629@discussion.autodesk.com...
Tony,

I am saying that most code IS forward compatible. Like I said, I WOULD expect code I written for AutoCAD Pre SP1 to work Post SP1 and possibly beyond (although there are many documented cases in MS Windows where this is not always the case.)

Even AutoCAD acknowledges that backwards compatibility may not work, which is why it (backwards compatibility) is not supported.
See "API and Script Compatibility" here:
http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=2935303

As far as LISP is concerned, I admit that I have no experience with versioning of it, but I expect that if AutoCAD 2005 LISP defines a function that AutoCAD 2004 LISP doesn't define, my LISP code will not work with AutoCAD 2004.

As far as VBA is concerned, If I program for a newer interface for say IAcadUtility2, which doesn't exist in Acad2004, this code will not even run, erroring out with an unknown type. And have those of you with both 2005 and 2006 installed ever noticed that the newer (2006) type libraries are always used in VBA?

Unfortunately, I can not comment on ARX, that is not my area of expertise. But if I expect a function exported from any exe or dll to exist and it doesn't, this will stop a program from running.

MS COM in general has had many problems with this very scenario (google DLLHELL). A program installs an older dll to the system, which may break a program expecting a newer version of said dll (could even prevent the system from running altogether, BSOD in the worst cases).

.NET is supposed to prevent many of these problems, but AutoCAD is dependant on specific versions of DLLs to run properly, most of which are written in ARX which have their own dependancies.

As an example of where NOT installing a required service pack breaks functionality, see the beginning of this thread.

If Laurence does install SP1 for AutoCAD 2005 on the Client, his code should then run. I am sure he will let us know if this is not the case.

C
Message 12 of 13
cgay
in reply to: Anonymous

The issue that Laurence started with:

Code written against the AutoCAD 2005 SDK compiled and ran on his development machine. This was using version 16.1.84.0 of the managed libraries.

He then proceeded to install on the client computer which was AutoCAD 2005 as well, but did NOT have the 16.1.84.0 versions of the managed libraries (Pre SP1 version 16.1.63.0) and this did NOT work.

Next he copied the 16.1.63.0 managed libraries to his development machine and recompilied.Then he redeploys to the client machine and all was well. He could just have easily updated the client to SP1 to resolve his issue.

That's it, problem solved. Foward compatibility works, backwards compatibility doesn't (even in minor releases) as proven.

Perhaps you could cite some examples to the contrary?
Message 13 of 13
Anonymous
in reply to: Anonymous

I really don't need you to recap the reason why
the OP's code would not run on another installation
of AutoCAD 2005. The reason is entirely self-evident.

However, you still seem to be ignoring the point
that it should not happen, and you continue to
ignore the simple fact that there is a difference
between compatiblity between service packs, and
major releases.

So, I'm going to say this once more.

No other AutoCAD API suffers from a dependence
on a specific service pack... PERIOD.

Applications built with those APIs will run on any
installation of the major release that is targeted,
regardless of what level of service pack is or is not
installed.

That's it, in plain simple English.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:5081444@discussion.autodesk.com...
The issue that Laurence started with:

Code written against the AutoCAD 2005 SDK compiled and ran on his development machine. This was using version 16.1.84.0 of the managed libraries.

He then proceeded to install on the client computer which was AutoCAD 2005 as well, but did NOT have the 16.1.84.0 versions of the managed libraries (Pre SP1 version 16.1.63.0) and this did NOT work.

Next he copied the 16.1.63.0 managed libraries to his development machine and recompilied.Then he redeploys to the client machine and all was well. He could just have easily updated the client to SP1 to resolve his issue.

That's it, problem solved. Foward compatibility works, backwards compatibility doesn't (even in minor releases) as proven.

Perhaps you could cite some examples to the contrary?

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