Problem with 64-Bit Windows & VB.Net 2.0 COM Class References

[kentheprogger]

Ive run into an extremely strange error which Im guessing has something to do with the pathing of the references in Windows XP 64-Bit.

The first time I ran into this problem was with Pepperwhite; a GPS mapping control kind of like Google Earth but 2D. I shrugged it off and used Visual Studio 2003 (.Net 1.1) and I was able to pull in that control no problem.

So today I needed to use the Shockwave Flash Object from Adobe (previously Macromedia) and I added as a reference from the COM tab no problem and when I tried to drag it to the form I got the error "Error: Check to see if ActiveX Control is Registered"; which I know is registered because I can use it in VS 2003. So I went into the references and under Shockwave Flash under path it said that it could not be found. So now knowing actually where the ActiveX control I manually added it. I was able to get it to the form at this point.

So pleased with my efforts I decided to run the program and BAM; the dreadful and annoying InvalidOperationException popped up.

An error occurred creating the form. See Exception.InnerException for details. The error is: Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

This was the same exact error I was getting when trying to run a form with the Pepperwhite control I mentioned earlier.

Ive tried running Filemon, Regmon, reinstalling VB.Net 2.0, but I have not been able to correct this problem.

Is there anyone else who has Windows XP 64-Bit edition that would be willing to test this to confirm that there is indeed a problem with COM controls and VB.Net 2.0? (Since they all run fine on VB.Net 1.1, this would be a problem with the new framework and or the Visual Studio 2005 IDE.)

Thanks so much,

Ken

 

[Nerseus]

Not sure if this will help, but have you tried changing the properties of your VB.NET 2005 project so that the target CPU is x86? It defaults to "Any CPU".

At my work weve run into numerous issues running 64bit development machines - a lot of ASP.NET issues and a few 3rd party vendors that didnt have 64 bit versions of their controls. I was suspicious when some of my favorite utilities (such as UltraMon, for dual monitors) have separate versions for 32 and 64 bit. Even Windows Media Player is different between the two versions.

Most of our devs have since switched to using a virtual machine setup as a 32bit windows xp and their main machine as 64 bit. Some of us (like me), opted to go for just a 32 bit windows xp even though the box is 64bit processor.

-ner

 

[kentheprogger]

Thanks Nerseus, you are indeed correct. I did some research and found this known issue for the IDE.

1.3 References to 32-bit COM components may not work in VB and C# Applications running on 64-bit platforms

Most existing COM components are only available for 32-bit platforms and will not run in a 64-bit process on a 64-bit platform (although they will run correctly in a 32-bit process on a 64-bit platform). VB and C# applications that reference these 32bit COM components will not run by default on a 64-bit platform because by default the application will launch as a 64-bit process.

The problem appears when a project with one or more COM references is:

Migrated to VS 2005 and executed on 64 bit platforms
-or-
Created using VS 2005 on 64 bit platforms
In VS 2005 the VB and C# compilers use the platform target property to determine if the.exe or .dll should run in 32 bit or 64 bit CPU architecture mode. The default setting for this property in Visual Studio 2005 is set to AnyCPU which indicates that the application can run in either 32 and 64 bit mode, depending on the host platform. In this situation you may see an error such as "Cannot instantiate class