Compact SQL - Any CPU Build

[Smurfman-MSDN]

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

 

[Colbert Zhou [MSFT]]

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Colbert Zhou [MSFT]]

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/...881-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.â€


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

Best regards,
Colbert Zhou ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Colbert Zhou [MSFT]]

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/...881-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.â€


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

Best regards,
Colbert Zhou ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Smurfman-MSDN]

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

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Colbert Zhou [MSFT]]

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:
(e-mail address removed).

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

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Smurfman-MSDN]

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

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:
(e-mail address removed).

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

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Smurfman-MSDN]

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

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:
(e-mail address removed).

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

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Smurfman-MSDN]

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

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:
(e-mail address removed).

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

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Colbert Zhou [MSFT]]

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/...881-9C32-3A6CE53384D9&displaylang=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:
(e-mail address removed).

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

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:
(e-mail address removed).

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

:

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Smurfman-MSDN]

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

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/...881-9C32-3A6CE53384D9&displaylang=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:
(e-mail address removed).

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

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:
(e-mail address removed).



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

:

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Colbert Zhou [MSFT]]

Hello Jeff,

As to your new question, by default there is only one SQL Server Compact 3.5
in the prerequisites dialog. If we want to make a x64 version of SQL Compact
3.5, we need to write the bootstrapper package by ourselves.

Please refer the following blog and thread for detailed steps and
information,
http://blogs.msdn.com/sqlservercomp...rapper-package-in-visual-studio-2008-sp1.aspx

http://www.mydatabasesupport.com/forums/ms-sqlserver/415856-ms-sql-ce-3-5-sp1-clickonce.html

Have a nice weekend!

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:
(e-mail address removed).

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

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/...881-9C32-3A6CE53384D9&displaylang=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:
(e-mail address removed).

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

:

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:
(e-mail address removed).



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

:

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/details.aspx?FamilyId=DC614AEE-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 ([email protected], 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:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#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/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.