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

[kentheprogger]

I've run into an extremely strange error which I'm 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.

I've 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 we've run into numerous issues running 64bit development machines - a lot of ASP.NET issues and a few 3rd party vendors that didn't 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 …" when you debug or run these applications.

To resolve this issue

Set the platform target property to 'X86' for your VB or C# projects that have references to COM components.

For C# Projects:

Right click the project in the solution explorer and open 'properties'
Choose the Build tab
Set the Platform Target property to 'X86'
For VB Projects:

Right click the project in the solution explorer and open 'properties'
Choose the Compile tab
Press the Advanced Compile Options… button
Set the Target CPU property to 'X86'
Express Edition:

The VB and C# Express products to not expose the Target property inside the development environment. You will need to carefully modify the project file using a text or XML editor.

Close the project and/or solution
Select Open File from the File menu
Navigate to the project directory, and highlight the project file
Press the Open button, the project file should open in the XML editor
Locate the first <PropertyGroup> section and add the following line: <PlatformTarget>x86</PlatformTarget>

Save the project file
Reopen the project and/or solution using Open Project/Solution from the File menu
Continue with development, debugging, and testing
Alternatively, if the application is targeted to 64-bit platforms, you can ensure that the COM controls added to the application have 64-bit equivalents on the development and deployment computers.

--

I really wish there was an easier way to upgrade programs to 64-bit since vendors are now only selling 64-Bit Processors yet you cannot fully utilize the power unless your running a 64-Bit version of that process. By the time everyone is caught up to 64-Bit i'm almost positive there will be a 128-bit processor available.