Vista - Compact SQL - Any CPU Build

Using VS2008 SP1 on Vista Ultimate 64bit

Moving Project from XP Sp3 machine on same VS2008
Experienced the following:
1) Was able to compile my project with no errors
2) Installed the project with no errors from VS2008

Tried to run the program and a few things:

1) Originally I was reading a registry key created during setup for a
default export location, the Key was installed in XP system to
HKLM\Software\Manufacturer\Program Name\DefaultExportLoc as example

When installed on Vista 64 bit, the key is moved to
HKLM\Wow6432Node\Manufacturer\Program Name\DefaultExportLoc

So when the program ran to read the key, it could not find it.

I resolved this by moving everything to HKCU


QUESTION #1 - WHAT IS THE PROPER WAY TO LOOK FOR KEYS ON A 64bit MACHINE
WHERE PROGRAMS GET INSTALLED TO THE Wow6432Node key instead of the
HKLM\SOFTWARE root.

2) Once past that I was getting the error: unable to load dll sqlceme35.dll

I found a post on another forum - could be dated, that stated I needed to
change my project from Any CPU to x86 - this did resolve my install...

QUESTION #2 - IS THIS THE PROPER WORK AROUND FOR THIS, OR IS THERE A PROPER
WAY TO ALLOW THE ANY CPU COMPILE TO WORK?

Thanks
J

Hello Jeff,

Thanks for using Microsoft Newsgroup Support Service, this is Colbert Zhou
[MSFT] and I will be working on this issue with you.

The following are some explanations for what the Wow6432Node is in the
registry and why we encounter the first issue. And later I will give my
solutions to both of your questions.

*The Wow6432 registry entry indicates that you're running a 64-bit version
of Windows. The OS uses this key to present a separate view of
HKEY_LOCAL_MACHINE\SOFTWARE for 32-bit applications that run on a 64-bit
version of Windows. If a 32-bit application queries or writes a value under
the HKEY_LOCAL_MACHINE\SOFTWARE\<company>\<product>, it is redirected to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\<company>\<product> by system.

*In our situation, by default our MSI install program is 32 bit and it
tries to write a value to HKLM\SOFTWARE. As a result of we are running on
64 bit system, this registry writing is redirected to
HKLM\SOFTWARE\Wow6432Node. But, our application is compiled as 64 bit
application. So later when it tries to read the registry key, it reads from
HKLM\SOFTWARE directly where the written key does not exist.


THE SOLUTIONS (It depends whether you want to compile your application as
32 bit or 64 bit)

*If we want to compile it as 32 bit just like we did in the XP system.
Changing the option from Any CPU to x86. This will resolve both the issue 1
and issue 2.

*If we want to compile it as 64 bit application.
1) To resolve the first issue, we need to select the deployment project.
And in the Properties window, we change the TargetPlatform from x86 to x64.
This makes your registry key is written in HKLM\SOFTWARE instead of the
Wow6432Node.
2) To resolve the second issue, please download and install the SQL Server
Compact 3.5 SP1 x64 version,
http://www.microsoft.com/downloads/d...AEE-7E1C-4881-
9C32-3A6CE53384D9&displaylang=en#filelist
Please also not the Additional Information in that link,
"Due to changes in SQL Server Compact SP1 and additional 64-bit version
support, centrally installed and mixed mode environments of 32-bit version
of SQL Server Compact 3.5 and 64-bit version of SQL Server Compact 3.5 SP1
can create what appear to be intermittent problems. To minimize the
potential for conflicts, and to enable platform neutral deployment of
managed client applications, centrally installing the 64-bit version of SQL
Server Compact 3.5 SP1 using the Windows Installer (MSI) file also requires
installing the 32-bit version of SQL Server Compact 3.5 SP1 MSI file. For
applications that only require native 64-bit, private deployment of the
64-bit version of SQL Server Compact 3.5 SP1 can be utilized."


If you have any future questions or concerns, please feel free to let me
know! Have a nice day!

Best regards,
Colbert Zhou (colbertz@xxxxxx, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxx.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/...tance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hello Jeff,

Thanks for using Microsoft Newsgroup Support Service, this is Colbert Zhou
[MSFT] and I will be working on this issue with you.

The following are some explanations for what the Wow6432Node is in the
registry and why we encounter the first issue,

*The Wow6432 registry entry indicates that you're running a 64-bit version
of Windows. The OS uses this key to present a separate view of
HKEY_LOCAL_MACHINE\SOFTWARE for 32-bit applications that run on a 64-bit
version of Windows. If a 32-bit application queries or writes a value under
the HKEY_LOCAL_MACHINE\SOFTWARE\<company>\<product>, it is redirected to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\<company>\<product> by system.

*In our situation, by default our MSI install program is 32 bit and it tries
to write a value to HKLM\SOFTWARE. As a result of we are running on 64 bit
system, this registry writing is redirected to HKLM\SOFTWARE\Wow6432Node.
But, our application is compiled as 64 bit application. So when it tries to
read the registry key, it reads from HKLM\SOFTWARE directly where the
written key does not exist.



THE SOLUTIONS (It depends whether you want to compile your application as 32
bit or 64 bit)

*If we want to compile it as 32 bit just like we did in the XP system.
Changing the option from Any CPU to x86. This will resolve both the issue 1
and issue 2.

*If we want to compile it as 64 bit application.
1) To resolve the first issue, we need to select the deployment project. And
in the Properties window, we change the TargetPlatform from x86 to x64. This
makes your registry key is written in HKLM\SOFTWARE instead of the
Wow6432Node.
2) To resolve the second issue, please download and install the SQL Server
Compact 3.5 SP1 x64 version,
http://www.microsoft.com/downloads/d...ng=en#filelist
Please also not the Additional Information in that link,
“Due to changes in SQL Server Compact SP1 and additional 64-bit version
support, centrally installed and mixed mode environments of 32-bit version
of SQL Server Compact 3.5 and 64-bit version of SQL Server Compact 3.5 SP1
can create what appear to be intermittent problems. To minimize the
potential for conflicts, and to enable platform neutral deployment of
managed client applications, centrally installing the 64-bit version of SQL
Server Compact 3.5 SP1 using the Windows Installer (MSI) file also requires
installing the 32-bit version of SQL Server Compact 3.5 SP1 MSI file. For
applications that only require native 64-bit, private deployment of the
64-bit version of SQL Server Compact 3.5 SP1 can be utilized.�


Please let me know if you have any future questions or concerns! Have a nice
day!

Best regards,
Colbert Zhou (colbertz@xxxxxx, remove ‘online.’)
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxx.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support Engineer
within 1 business day is acceptable. Please note that each follow up
response may take approximately 2 business days as the support professional
working with you may need further investigation to reach the most efficient
resolution. The offering is not appropriate for situations that require
urgent, real-time or phone-based interactions or complex project analysis
and dump analysis issues. Issues of this nature are best handled working
with a dedicated Microsoft Support Engineer by contacting Microsoft Customer
Support Services (CSS) at
http://support.microsoft.com/select/...tance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.



"Smurfman-MSDN" <smurfman@xxxxxx> wrote in message
newsD8961A8-D757-40DA-AF97-D437D409ECD0@xxxxxx

Colbert, thank you very much this helps a great deal.

So, I downloaded and installed SQL Compact 3.5 SP1 x64 (x86 was apparently
already installed according to my attempt to install it).

My quesiton is this - suppose I want to compile for both platforms - as I
may never know which OS a person might have.

Do I have to have two projects, or do I have to compile the same one 2 times
one each, can I automatically build both.

Which leads me back to my question - if I compiled for x64, do I understand
correctly, that my logic that was looking for
HKLM/SOFTWARE/Manufacturer/Program would automatically be re-directed to the
Wow6432Node

I worked around this by changing project to compile for x86 yesterday, but I
don't know if this is the correct solution.

Much appreciated.

J

"Colbert Zhou [MSFT]" wrote:

Hello Jeff,

Yes, compiling for x86 is the correct and most simple solution! In this
case, our application can be installed on both of the x86 and x64 platform.
Just the application itself is x86 version.

But if we want to compile it as x64 version, the built application can only
be installed on x64 platform, other than x86. In this case, we will meet the
error you mentioned in your first post because the setup and our application
itself have mismatch platform version. The setup is x86 and writes registry
key to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\, but our application is x64.
So the registry access is not directed. It reads directly from
HKEY_LOCAL_MACHINE\SOFTWARE\. So, if we want to compile an x64 version, we
need to select the Setup project. And in the Properties window, we change
the TargetPlatform from x86 to x64. This makes the setup matches the version
of our application. So the registry location will be consistent.

But please note that the x64 version application can make full usage of the
x64 machine’s resource and will have better performance, but it will not
run in the x86 client machines.

For more information about x64 registry redirection, please read the
following KB article
http://support.microsoft.com/kb/896459


Best regards,
Colbert Zhou (colbertz @online.microsoft.com, remove ‘online.’)
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxx.



"Smurfman-MSDN" <smurfman@xxxxxx> wrote in message
news:251EF45F-96A5-4D0D-A81A-D0E5588BD1B4@xxxxxx

Thank you very much. Probably for the purpose of this application I will
leave it so it can install on either x86 or x64.

However, lets suppose I wanted to be able to do both.

1) Could I have the installer (setup) project determine which platform I am
installing on, and then use one of two built projects within?

2) Or would I have to write a separate project, that did this detection and
used one of two built projects (setup projects) in which I would have
compiled two times one for x86 and one for x64...

If the later is true, I am thinking a simple form - could be HTML form, that
detects the platform and provides two links on the HTML form, one for the
Setup.exe for the x86 and one for the setup.exe for the x64. In the x64
option, I would like to give a recommended install button of the x64 build,
but allow the user to still install the x86 build - the button or link would
point to the install package that I built from my solution.

Any suggestions to accomplish this? I understand that no matter what I do,
I will need to build the project twice with two differenct CPU settings.

Thanks
J

"Colbert Zhou [MSFT]" wrote:

Well, I am kind of back to square one.

Here is the makeup of my solution:
3 Projects
- 1 is main project with form
- 2 is a dll with some custom messages and functions
- 3 is the setup project

1 and 2 are set for Any CPU in Compile settings.
3 is set for x64

I compiled with no errors and ran the installer from VS2008
The installer installed to D:\Program Files and not to D:\Program Files
(x86) which is exactly what I expected.

The Registry Keys are set in the Setup Program as

HKLM --> Software --> Manufacturer --> Program Name --> Keys and Values

After the install, I confirmed the keys were created under
HKLM\SOFTWARE\My Company\ProgramName

and Not the HKLM\SOFTWARE\Wow6432Node

This was good.

ONLY - when I perform this operation

My.Computer.Registry.GetValue( "HKEY_LOCAL_MACHINE\SOFTWARE\My
Company\Program", "ValueName", "" )

I do not get a value returned. The return is Nothing.

I don't think it is looking in the correct location.

Any ideas?
Thanks
J

"Colbert Zhou [MSFT]" wrote:

I think I got the x64 thing resolved from my last post. I still have other
questions I posted, but the Any CPU for the solution properties and the x64
for the setup, must still compile to x86 and not x64

I changed the solution properties to x64 and then rebuilt and re-installed ,
and then the get registry value worked.

Would this be the correct method?
J

"Colbert Zhou [MSFT]" wrote:

Hello Jeff,

Yes, your approach is right. We only need one solution, but compile our
application to x86 and x64 version respectively. And then let the user to
choose the right version to download and install depends on their system
architecture.

For example, the mentioned SQL Compact Edition SP has x86 and x64 version
for download from Microsoft site,
http://www.microsoft.com/downloads/d...ng=en#filelist


Best regards,
Colbert Zhou (colbertz @online.microsoft.com, remove ‘online.’)
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxx.



"Smurfman-MSDN" <smurfman@xxxxxx> wrote in message
news:F664187D-6FD8-43B4-AC4D-361E77129148@xxxxxx

Thank you.
I downloaded the x64 bit a while back when you first mentioned. And
installed it.

Does this mean that when I select an x64 bit build and the Prerequisite for
Compact SQL 3.5 that the compiler will automatically know to build with x64
since it is installed? And create the auto download for a x64 bit install?

In other words, there was no setting in the pre-req's to distinquish between
x86 and x64 or both as in the case of some of the pre-req's (such as C++
Runtime Libraries has two seperate, where as Crystal Reports has one that is
both x86 and x64)

SQL Server Compact 3.5 does not show either x86 or x64 just a single entry.

Thanks
J

"Colbert Zhou [MSFT]" wrote: