Re: Compact SQL - Any CPU Build

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/details.aspx?FamilyId=DC614AEE-7E1C-4881-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: msdnmg@xxxxxxxxxxxxxx



"Smurfman-MSDN" <smurfman@xxxxxxxxxxxxxxxx> wrote in message news:F664187D-6FD8-43B4-AC4D-361E77129148@xxxxxxxxxxxxxxxx
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, 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@xxxxxxxxxxxxxx



"Smurfman-MSDN" <smurfman@xxxxxxxxxxxxxxxx> wrote in message
news:251EF45F-96A5-4D0D-A81A-D0E5588BD1B4@xxxxxxxxxxxxxxxx
> 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,
>>
>> 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 (colbertz@xxxxxxxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxx
>>
>> ==================================================
>> 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.
>>
>>


.

Relevant Pages

  • Re: Compact SQL - Any CPU Build
    ... After the install, I confirmed the keys were created under ... our application can be installed on both of the x86 and x64 platform. ... But if we want to compile it as x64 version, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.general)
  • Re: Compact SQL - Any CPU Build
    ... our application can be installed on both of the x86 and x64 platform. ... But if we want to compile it as x64 version, the built application can only be installed on x64 platform, other than x86. ... already installed according to my attempt to install it). ...
    (microsoft.public.dotnet.general)
  • Re: Compact SQL - Any CPU Build
    ... leave it so it can install on either x86 or x64. ... compiled two times one for x86 and one for x64... ... But if we want to compile it as x64 version, ...
    (microsoft.public.dotnet.general)
  • Re: Compact SQL - Any CPU Build
    ... I think I got the x64 thing resolved from my last post. ... compiling for x86 is the correct and most simple solution! ... But if we want to compile it as x64 version, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.general)
  • RE: Windows Update Error on XP 64bit: update is redirected from v6
    ... I have resolved this issue on my XP x64 system. ... The MS support guy had me registering x86 dll's. ... When Windows Update is reinstalled it should work ...
    (microsoft.public.windowsupdate)
Loading