In this post, I’m working on a problem that is pertaining to a 64 bit version of AutoCAD loading a COM enabled .NET assembly – however this information should apply to any x64 executable calling any x64 COM assembly.   Replace AutoCAD with <YourApp.exe> and you should be good to go =)

The first thing I did was to ensure each of the projects had been set to build for  “ANY CPU”.   This got the ball of fun rolling.   We have a VLX which instantiates the COM class using vlax-get-or-create-object.  When called this would constantly return nil.   Of course this all works just peachy when running an x86 build of AutoCAD.   At this point my breakpoints would appear in Visual Studio as disabled and would happily inform me that “The breakpoint will not currently be hit”.

This usually results when the incorrect DLL is being loaded, or when the PDB file is missing.   Once Visual Studio is running in debug mode you can bring up the Modules window from the Debug/Windows/Modules menu.  This should show you all the assemblies involved in the current session as well a bunch of other information including their paths.  The assembly in question was not listed here – so at this point I’m assuming that Windows cannot find the dll.

Junk in the Registry

I am now thinking that I have orphaned and duplicated types and CLSIDs in the registry, likely pointing to other builds of the dlls.   If the GUIDs for the classes or types changed you end up with a lot of junk in the registry.   I don’t trust those registry “cleaner” apps and in the interest of keeping my OS working – I chose to manually search out and nuke all the registry references manually.  This can be done by searching both for your assembly’s type name, and COM exposed class names in regedit.  A lot of this was done in the HKEY_CLASSES_ROOT root.  After all of that the problem still exists..

Wow6432Node Registry Keys

Registry keys were a two part problem. After dealing with the junk in the registry, I found I also had to deal with the x86 registry redirection.   DraftLogic has been until this point limited to x86 architecture as a result of  the VB6 code not being x64 friendly.   As a result of this, all of the needed keys had been placed in the WOW6432Node of the appropriate software registry sections.   This was the easiest wall to find and hop over.  Unfortunately, this also didn’t solve the problem.

Improperly Registered Assemblies-thanks for nothingVisual Studio

So the next and fortunately final problem turns out that Visual Studio 2005/2008 (unsure about 2010) does not properly register assemblies.  Turns out the last piece of the solution is pretty simple – couple changes to the project.  What’s happening is that Visual Studio is running the x86 build of regasm.exe to register the assemblies on run, probably because Visual Studio is an x86 app itself.  This results in all kinds of x64 hating… To solve this we have to change two things in the COM enabled projects.

First though, I created a new build configuration called x64 so these changes would not affect in my ANY CPU configuration – which will be used to build my shipping assemblies.  It is also important to note that this problem is MOSTLY only a problem when running code from the IDE.  Assemblies installed and registered using an installer should not have this problem if the installer takes into consideration the “bitness” of AutoCAD (or any application calling your COM enabled dll).  ie.  Installshield asks the user on install what “bitness” of AutoCAD they are using, and the assemblies are registered as needed.  It may also be possible to register an assembly using both the 32 and 64 bit versions of regasm – but I have not tried this.

So with the new x64 configuration created I edited the properties of each COM enabled project  I unchecked “Register for COM interop” and added a post-build event command line of:

%Windir%\Microsoft.NET\Framework64\v2.0.50727\regasm $(TargetPath) /register /codebase /tlb

This would ensure that my COM enabled assemblies were properly registered for use by 64 bit  applications.

After all that, my breakpoints were finally hit, and I could actually start working out the x64 specific bugs. Too bad we couldn’t have moved this to ObjectARX.NET instead – then this would have been a non-issue =)  In retrospect, each of these problems were a contributing factor and each needed to be resolved. 

Hopefully if you are facing a similar issue this post helps you get over at least a couple of the walls!

I needed to install AutoCAD Map 3D 2011  to debug some ObjectARX code I’ve been working on so I downloaded the 32 bit installer and fired it up only to be informed that my platform was unsupported and I would need to install the 64 bit version.  grrrr.

Google had very little to say on the topic.  More junk about hacking MSI files with Orca.  I took a look at setup.ini and there were far too many references to x64 – I don’t have time for this…Finally I came across the Longbow Software Converter.  The product claims to modify your setups to allow the 32 bit installers to work on x64 operating systems, 40$.  I couldn’t find any reviews or testimonials so I figured I’d give it a shot…

So here is your first testimonial Longbow Software =)

This actually worked great.  Bought the convert, installed it to a virtual machine.   The interface is dead simple – paste or browse to the location of the AutoCAD installation files and press Convert.  Keep in mind if you’re running from a DVD you’ll need to copy the contents of the DVD to your PC or a network share so the files can be edited.  I pointed the converter to an install on a network share.  It chugged away for about a minute (keeping in mind this was on an underpowered VM).  Within a matter of minutes I had AutoCAD Map 3D 2011 installing on my Vista x64 box with no problems.  Ran AutoCAD and it seems to fire up no problem. 

Bear in mind – for AutoCAD to work with anything Oracle – you need to have the 32 bit Oracle client running on your machine.

40$ well spent IMO.

The problem is this.   x64 Applications cannot use the x86 driver.  In my previous attempts to get basic Oracle/ODP connectivity on my x64 Vista machine I ended up running the 11g x86 Oracle client.  Today I was back to the Oracle download site – and lookie lookie.  They’ve released an Oracle Server 2008 x64 client!  2008 is basically Vista so, maybe, just maybe – I thought Oracle will give us some x64 love.  Here are some steps that will help you get running:

First thing is first.  Backup your TNSnames.ora.  Its found in the network\admin folder. 

Next I un-installed the x86 11.1.0.6 client.   Delete the leftovers with windows explorer.

Next download both the 11.1.0.7 client for both x86 and x64 (yes, we need to run with both…)

First I installed the x64 client.  I like to do full runtime installations. 

Next, I copy my backed up tnsnames.ora into the network\admin folder.

Now fire up Map 2010 x64 – connect to Oracle server – Success!  Happy Happy Days.  Unfortunately, fire up Toad for Oracle (which is still 32 bit) and it fails with an error of “Cannot find OCI.DLL”.  Doh.

So, I go ahead and install the Oracle 11.1.0.7  x86 client.  I install it to the client_2 folder.  Then copy my tnsnames backup into the network\admin folder in the client_2 folder.  Restart Toad, and success!

Now I want to check one last thing.  Last time I was dealing with this fun issue – I had to set my development projects to only run in x86 mode.  So, I fire up my FullCircle development project and try it out.  Running IIS in x86 mode works.   Running IIS in x64 mode failed..

The ‘MSDAORA’ provider is not registered on the local machine

It seems the Microsoft MSDAORA provider doesn’t exist in x64 – so change your connection to use the Oracle OraOLEDB.Oracle instead and x64 projects run no problem.  It would be perfect to one day get one install that does both x86 and x64 – but for now, I’m content with this setup.

First, download and install Oracle 11g ODAC and Oracle Developer Tools for Visual Studio. (Link requires registration)   This should get the 32bit stuff installed.   I’m still using an Oracle 10g R2 server.  You will likely need to grab a copy of the TNSnames.ora for your existing client folder and place it in the appropriate tree of the 11g product home.

This however is not enough to get .NET working with ODP.  Go to the folder where you extracted the zip.  We need to find the Oracle.DataAccess.dll.  This can be found in the file named filegroup4.jar, in the stage\components\oracle.ntoledb.odp_net_2.  Winrar will open .jar files if needed.  Extract the Oracle.DataAscess.dll file.

For now, I’ve put a copy of this file in my projects lib folder.  I then added a reference directly to this file from all projects that need ODP access. 

Keep in mind – before you ship you may want to remove this reference and ensure that the .DLL file doesn’t get included in your build.  This should get your Vista x64 box developing with ODP.

To Oracle – come on guys.  Give us some Vista x64 love!