Invalid Cast Exception Occurs when changing target cpu option in VS.
-
I've written a routine that gets the windows installation key from the registry. This routine is just one part of a bigger application that I'm building. However, I have a problem with the routine not running correctly when Visual Studio's Target CPU option is changed from AnyCPU to x86. Note: I'm running a 64bit OS, but I want the app to specifically target 32bit platforms. When VS is set to AnyCPU the routine works fine. When set to x86 an invalid cast exception of "Unable to cast object of type 'System.Int32' to type 'System.Byte[]'" occurs at the DirectCast line.
Dim aryDigitalProductID As Byte()
Dim objDPID As Object = My.Computer.Registry.GetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\", "DigitalProductId", 0)If objDPID Is Nothing Then Return "Not Available" aryDigitalProductID = DirectCast(objDPID, Byte())I'm using the directcast because I prefer to code with Option Strict set to on. However, if I turn Option Strict off, and coerce objDPID to an array the invalid cast exception still occurs. Does anyone know how to overcome this so the routine would work when targeted specifically at a 32bit platform? Also, when the AnyCPU option is selected, how does the compiled AnyCpu code differ from x86 code? Any help would be greatly appreciated. (As you can probably infer, I'm not completely au fait with VB.Net and VS.)
-
I've written a routine that gets the windows installation key from the registry. This routine is just one part of a bigger application that I'm building. However, I have a problem with the routine not running correctly when Visual Studio's Target CPU option is changed from AnyCPU to x86. Note: I'm running a 64bit OS, but I want the app to specifically target 32bit platforms. When VS is set to AnyCPU the routine works fine. When set to x86 an invalid cast exception of "Unable to cast object of type 'System.Int32' to type 'System.Byte[]'" occurs at the DirectCast line.
Dim aryDigitalProductID As Byte()
Dim objDPID As Object = My.Computer.Registry.GetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\", "DigitalProductId", 0)If objDPID Is Nothing Then Return "Not Available" aryDigitalProductID = DirectCast(objDPID, Byte())I'm using the directcast because I prefer to code with Option Strict set to on. However, if I turn Option Strict off, and coerce objDPID to an array the invalid cast exception still occurs. Does anyone know how to overcome this so the routine would work when targeted specifically at a 32bit platform? Also, when the AnyCPU option is selected, how does the compiled AnyCpu code differ from x86 code? Any help would be greatly appreciated. (As you can probably infer, I'm not completely au fait with VB.Net and VS.)
The problem you're having is from the way x64 windows runs x86 code. The x64 regedit and the x86 regedit point to different hives. x64 windows running x86 code will actually substitute a 32bit registry in much the same way it substitutes the 32bit Program files directory. Your program is actually accessing the key at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion when running in x86 mode, instead of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion that it gets in anyCPU or x64 mode, and since the DigitalProductId key doesn't exist there, you're getting your default value which is 0. That's where the System.Int32 comes from. If you run yor program on an x86 OS it will work, it's only failing because you're specifying x86 on an x64 OS. Leave it on AnyCPU and you should be fine. The code that VS compiles doesn't change when you change the Target CPU, it only changes a header flag that the interpreter reads and forces it to use the x86 interpreter.
-
The problem you're having is from the way x64 windows runs x86 code. The x64 regedit and the x86 regedit point to different hives. x64 windows running x86 code will actually substitute a 32bit registry in much the same way it substitutes the 32bit Program files directory. Your program is actually accessing the key at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion when running in x86 mode, instead of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion that it gets in anyCPU or x64 mode, and since the DigitalProductId key doesn't exist there, you're getting your default value which is 0. That's where the System.Int32 comes from. If you run yor program on an x86 OS it will work, it's only failing because you're specifying x86 on an x64 OS. Leave it on AnyCPU and you should be fine. The code that VS compiles doesn't change when you change the Target CPU, it only changes a header flag that the interpreter reads and forces it to use the x86 interpreter.
Thanks for the explanation, I'd forgotten I'd posted this question it was that long ago :) Your answer makes perfect sense now it has been explained. I can't even remember now why I specifically wanted to target x86 architecture in the first place as the finished program was designed to run on either platform. See this link for the finished program / CP article. Retrieving Information From Windows Management Instrumentation[^]
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
-
Thanks for the explanation, I'd forgotten I'd posted this question it was that long ago :) Your answer makes perfect sense now it has been explained. I can't even remember now why I specifically wanted to target x86 architecture in the first place as the finished program was designed to run on either platform. See this link for the finished program / CP article. Retrieving Information From Windows Management Instrumentation[^]
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
You're welcome. I had been searching for what AnyCPU actually did a couple days ago and this thread was one of the first hits on google, so now that I know I figured I should update it for future searchers.