topic Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit in .NET Forum

.NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 14:34:48 GMT

Hello all. I have an assembly that loads correctly in AutoCAD 2009 on XP 32-bit, but not on AutoCAD 2009 on Vista 64-bit. The target framework is set to 2.0, which is present on the XP machine, with the 3.5 framework available on the vista machine. I've tried setting the target to x86 instead of any, and still get the same error. Also, the vista machine is running a virtual machine under vmware.

Anyone have any ideas at things i could check? I know there's quite a few variables here, so any ideas on narrowing things down would be appreciated.

Thanks,

-Chris

{code}
Command: netload
Cannot load assembly. Error details: System.BadImageFormatException: Could not
load file or assembly
'file:///C:\Users\vmcad64\Documents\BackgroundCleaner.dll' or one of its
dependencies. An attempt was made to load a program with an incorrect format.
File name: 'file:///C:\Users\vmcad64\Documents\BackgroundCleaner.dll'
at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase,
Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark,
Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.LoadFrom(String assemblyFile)
at Autodesk.AutoCAD.Runtime.ExtensionLoader.Load(String fileName)
at loadmgd()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure
logging.
To turn this feature off, remove the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog].
{code} Edited by: chrisshoemaker4224 on Jun 16, 2009 12:05 PM

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 16:21:12 GMT

Does your assembly use P/Invoke on AutoCAD native APIs?

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");

wrote in message
news:6202474@discussion.autodesk.com...
Hello all. I have an assembly that loads correctly in AutoCAD 2009 on XP
32-bit, but not on AutoCAD 2009 on Vista 64-bit. The target framework is set
to 2.0, which is present on the XP machine, with the 3.5 framework available
on the vista machine. I've tried setting the target to x86 instead of any,
and still get the same error. Also, the vista machine is running a virtual
machine under vmware. Anyone have any ideas at things i could check? I know
there's quite a few variables here, so any ideas on narrowing things down
would be appreciated. Thanks, -Chris {code} Command: netload Cannot load
assembly. Error details: System.BadImageFormatException: Could not load file
or assembly 'file:///C:\Users\vmcad64\Documents\BackgroundCleaner.dll' or
one of its dependencies. An attempt was made to load a program with an
incorrect format. File name:
'file:///C:\Users\vmcad64\Documents\BackgroundCleaner.dll' at
System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase,
Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark,
Boolean throwOnFileNotFound, Boolean forIntrospection) at
System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence
assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at
System.Reflection.Assembly.LoadFrom(String assemblyFile) at
Autodesk.AutoCAD.Runtime.ExtensionLoader.Load(String fileName) at loadmgd()
WRN: Assembly binding logging is turned OFF. To enable assembly bind failure
logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog]
(DWORD) to 1. Note: There is some performance penalty associated with
assembly bind failure logging. To turn this feature off, remove the registry
value [HKLM\Software\Microsoft\Fusion!EnableLog]. {code} Edited by:
chrisshoemaker4224 on Jun 16, 2009 12:05 PM

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 16:25:16 GMT

Not specifically...but I am using unmanaged AutoCAD COM componants through Interop (which i suspect is the same thing).

I'm using VB.NET to port a VBA application through COM Interop.

-Chris

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 17:21:05 GMT

chrisshoemaker4224 wrote:

> Not specifically...but I am using unmanaged AutoCAD COM componants
> through Interop (which i suspect is the same thing). I'm using VB.NET
> to port a VBA application through COM Interop. -Chris

I didn't have any luck using early bound COM in assemblies that must run
both in 32/64bit, experiencing similar errors from what I recall. Using
the managed API is preferred, and late bound COM only when something is
missing from the API. That approach is working well for me and the
results run in any version of AutoCAD 2007 and higher.

Terry

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 17:36:24 GMT

Terry,

A lot of the code interfaces with the Sheet Set Manager API, which i believe is only accessible in early bound COM....so that alone would prohibit me from using an all-managed code project. Is it possible that two different versions might get around this? One compiled for 32-bit and the other for 64-bit?

-Chris

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 17:59:02 GMT

chrisshoemaker4224 wrote:

> A lot of the code interfaces with the Sheet Set Manager API, which i
> believe is only accessible in early bound COM.

I haven't explored it, but its very likely there are managed interfaces
for that as well.

> Is it possible that two different versions might get around this? One
> compiled for 32-bit and the other for 64-bit?

Should work, give it a try. If it does you can setup separate projects
and *link* in the common code.

In my case I avoid separate 32/64bit versions at all costs.

Terry

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 18:03:57 GMT

Terry W. Dotson wrote:

> I haven't explored it, but its very likely there are managed
> interfaces for that as well.

Or maybe not, that may be COM only.

Terry

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 19:50:32 GMT

If you're using late bound ActiveX or SSM, I'm pretty sure
your only option is two platform-specific releases.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");

wrote in message
news:6202660@discussion.autodesk.com...
Not specifically...but I am using unmanaged AutoCAD COM componants through
Interop (which i suspect is the same thing). I'm using VB.NET to port a VBA
application through COM Interop. -Chris

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 21:43:47 GMT

Terry,

Side question...how are you tying into Excel with XL2CAD then? I wasn't aware that there are managed API's for Office...just COM.

-Chris

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 22:01:51 GMT

Terry W. Dotson wrote:

> setup separate projects and *link* in the common code.

Something to watch out for. If I'm not mistaken, code in a *linked*
file cannot be changed during the debugging process. Nothing like being
able to edit the code while debugging. 🙂

Terry

Re: .NET assembly loads in XP 32-bit, but not Vista 64-bit

Anonymous — Tue, 16 Jun 2009 22:08:50 GMT

chrisshoemaker4224 wrote:

> Side question...how are you tying into Excel with XL2CAD then? I
> wasn't aware that there are managed API's for Office...just COM.

For sake of discussion here, lets just say its late bound COM but
doesn't suffer the associated delays. It's true (AFAIK) that there are
no managed APIs for Office.

I believe I found you at ___pc.com? If that's you, email me at dotson
[at] dotsoft [dot] com and I'll explain how it works.

Terry