I am using Izpack for packaging my java application in the form of an installer. now i want to include 64 bit support for my application installer. My idea is to package both 32 and 64 bit java and mysql client for my installer and while installing ,our application installer should install 64 or 32 bit mysql/java depending up on the architecture of the server.
Could anyone help me do this? I was thinking of making a dropdownbox with values 32bit and 64 bit and depending on this value unpack the necessary files. but this seems to be crude. Does anyone have a better idea?
You could use the $SYSTEM_ variables to access the JAVA variables and grab the architecture from that.
$SYSTEM_os_arch will give you the architecture of the jre but not the machine. If that would work for you I would then make a condition from the os arch and install the correct supporting apps based on the conditions.
Related
I am trying to use the SQLite's .Net DLL to access some data on a local SQLite database. The problem is that i need a way arround this error because i need to develop a software for 32/64 bits platforms (by using VB.Net not C#).
How can i stick to the 32bit version of the DLL to allow 32bit users of my program use it too?
If it's not possible to work with the 32bit version of SQLite's DLL, is it possible to include both versions in my Installer and programaticly choose which version of the DLL should be used?
Or..is there any other way to access SQLite databases without this particular DLL? (Things in C/C++ are much easier when it comes to SQLite usage as i remember)
Thanks!
If you change your Target Platform to x86 instead of AnyCPU your code will be emitted as 32bit code also on 64bit systems and you could use just the 32bit dll of SQLite.
If you think that you are loosing some value working exclusively with x86 then I can give you this reference where the PRO and CONS of AnyCpu are critically examined.
To change the Target Platform use:
Menu BUILD, then Configuration Manager
Choose x86 from the Active Solution Platform combo.
If you don't have an x86 choice,
choose New and Select x86 and copy the default settings from AnyCpu.
I have some .NET code that I am looking into porting into being a Windows Store app.
This code does a few different things and one of the things it does has a dependency on being compiled as x86 instead of AnyCPU.
Is this going to be a problem? Can a Metro app be compiled as x86 and still be distributed on the Windows Store? Is being compiled as x86 going to stop it from being able to run in Windows RT? Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it? (so, the main executable is AnyCPU and this one assembly is x86).
Can a Metro app be compiled as x86 and still be distributed on the Windows Store?
Yes. However, it would only be installable for x86 installations.
Is being compiled as x86 going to stop it from being able to run in Windows RT?
Since Windows RT is designed to run only on ARM CPUs, compiling for x86 will stop it from being able to run on Windows RT.
Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it?
You could use conditional compilation symbols to include/exclude functionality as required in your code. https://stackoverflow.com/a/6587823/61385 shows an example of how to do this.
Just compile whatever libs you need and when you upload to app store just upload the one you want to. Check your apppackages folder and look for the .appxupload files.
I'm developing a C#/WPF app that talks to a USB device using some custom 32 bit dlls. It's developed as an x86 app, and installed with WIX. When I install the package on a 64-bit machine, the program files get installed to Program Files (x86) as I expect.
The dlls are installed to the SystemFolder using WIX. On 32-bit machines, this means C:\Windows\System32. On 64-bit, they end up in C:\Windows\SysWOW64. This is ok, but when I run my app, it is unable to find the dlls (it uses them via [DllImport...]).
So, what is the right way to make my app find the dlls, whether they are in System32 or SysWOW64?
Thanks
Tom
If it is a default C# app, it will automatically be a 64 bit app on 64 bit Windows (C3 defaults to 32 bit on 32 bit Windows). Go into the project properties in your development app and explicitly set the architecture (I think; I don't have Studio up right now) to 32 bit. If it is running as a 64 bit app, it won't be able to use your 32 bit DLLs.
Please check if the dll in application is of the same version as that in the sys32 or wow64 folder depending on your version of windows.
You can check that from the filesize of the dlls.
Eg: I faced this issue because my libeay.dll file in system32 had a different dll than my libeay.dll file in openssl application. I copied the one in sys32 into openssl and everything worked well.
In install4j, can you include both 32 and 64 bit versions of an application in one install package and let the user decide which to install if the OS is 64-bit? Would the easiest/best solution be to create three projects? i.e. one parent/two children? I'm hesitant to do this because the majority of the included files are not architecture-specific and I'd like to keep everything in one project.
I'm also not tied to install4j if another installer can accomplish this, especially WiX, which is used by other groups in our company.
Currently install4j cannot create a single media file for 32-bit and 64-bit. Since the 32-bit media file works on 64-bit Windows as well, this is usually not a big problem. Common 32-bit/64-bit media files may be implemented for install4j 6.
In any case, you do not need separate projects for 32-bit and 64-bit installers. You just add two media files in the "Media" step of the install4j IDE, one for the 32-bit installer and another one for the 64-bit installer, with different settings on the "32-bit or 64-bit" step of the media wizard.
As for platform specific files, just add two file sets and exclude them as appropriate in the "Customize project defaults->Exclude files" step of the media wizard.
I heard on Windows x64 architecture, in order to support to run both x86 and x64 application, there is two separate/different sets of Windows registry -- one for x86 application to access and the other for x64 application to access? For example, if a COM registers CLSID in the x86 set of registry, then x64 application will never be able to access the COM component by CLSID, because x86/x64 have different sets of registry?
So, my question is whether my understanding of the above sample is correct? I also want to get some more documents to learn this topic, about the two different sets of registry on x64 architecture. (I did some search, but not found any valuable information.)
I ran into this issue not long ago. The short answer is that if you run a 32 bit application on a 64 bit machine then it's registry keys are located under a Wow6432Node.
For example, let's say you have an application that stores its registry information under:
HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX
If you compile your application as a 64 bit binary and run it on a 64 bit machine then the registry keys are in the location above. However, if you compile your application as a 32 bit binary and run it on a 64 bit machine then your registry information is now located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX
This means that if you run both the 32 bit and 64 bit versions of your application on the same machine then they will each be looking at a different set of registry keys.
Your understanding is correct. There wouldn't be any need for a x64 app to access the x86 CLSIDs since it could never load those components anyway and vice versa.
If you want to create component for use by both x86 and x64 then you need to either create a pair of dlls one built for x86 and the other for x64 and register both in their appropriate parts of the registry. The regsrv32.exe in the System32 folder will perversely register the x64 component and the regsrv32.exe in the SysWOW64 folder will register the x86 component.
Alternatively build a .NET assembly for Any CPU which can used by either CPU architecture.
They aren't separate registries--one is a subnode of the other, and the OS does virtualization to make sure that 32bit apps get their keys and 64bit apps get their keys.
Here is the Wikipedia article on the WOW64 registry which may give you some of the information you are looking for:
http://en.wikipedia.org/wiki/WOW64
I run an x64 bit machine as my desktop; and I have never run into any issues with the different registry configurations.
Per MSDN, there is apparently a difference:
http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx
HTH
How to register .NET assembly to be used as COM in pure 64-bit application?
Problem:
By default, if you enable "Register for COM Interop" in build settings, it DOES NOT register type library for 64-bit.
Solution:
To register your assembly which is not in GAC on a 64-bit machine, open cmd window and do:
cd c:\windows\microsoft.net\framework64\v2.x.xxxxx
regasm /codebase "path to your compiled assembly dll"
This will eliminate "Class Not Registered Error" when using native C++ to instanciate .NET assembly as COM object.