I am wrestling with an issue I cannot understand. We have a ClickOnce deployment of a WPF application in Azure blob storage. The processor architecture is everywhere "msil" in this deployment. When it gets run from IE, it runs as a 32bit application on AMD64 computers. The desired behavior would be to run as 64 bit. Could someone please enlighten on where should I look to fix this problem?
I already managed to go through the hoops to build the assemblies as x64 and create the ClickOnce deployment as amd64. This combo will run as 64 bit. The desired behavior is to still have it "msil" so it can run as either 32-bit or 64-bit, depending on the operating system it will be running on.
Related
I set the azure app service to 64-bit mode:
, but then I run dotnet --info within the app service and it turns out that the system is under x86 (32 bit)
Q: So I wonder how can I switch the app service to 64-bit mode (win10-64x)?
P.s I've tried suggestion from How to change Azure App Service to 64-bit, but it doesn't work for me
In fact, the windows systems of our webapp sandbox environment are all 64bit. The option to switch in the portal is modified to process.
We can use
set pro
to check process is 64bit or 32bit.
After change platform on portal, it will take effect immediately.
1. Change to 32bit.
2. Change to 64bit.
You also can check Env on kudu site. It will change 64 bit process.
I have a VSTO addin which will not install on 32bit machines. (the error popup on install is: "This installation package is not supported by this processor type. Contact your product vendor.")
The addin uses Installshield to do the install.
The application builds with "AnyCPU".
It seems to force to 64bit if anything within installshield references a 64bit. (eg I have registry entries for my addin which are its Description, friendlyName, LoadBehavior and Manifest. These are located in HKLM/Software (64bit)/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin)
I don't really know if this needed?
So my fix is to have two releases... where one doesn't have any 64bit registry references.
How would I fix this? I've been toying around with the notion of ditching Installshield LE and moving to vs2017 with some other installer...
I have a VSTO addin which will not install on 32bit machines.
Do you mean the addin is not loaded by Office? or the install package itself fails to install?
I'll assume the addin is not loaded. I don't know how installshield controls the the package components bitness, but I will try to provide an answer that you can apply to any tool, as long as the following options are configurable in the tool.
With MSI packages installing VSTO addins you need to make sure your registry entries end up in the right registry hive, based on the bitness of your installed Office version, not the one of the OS.
So, for machines with Office x86 you have these registry:
on x86 OS: HKLM/Software/Microsoft/Office/Outlook/Addins/myAddin
on x64 OS & 32-bit Office: HKLM/Software/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin
The two paths above represent a single configuration in your MSI. i.e. if you create a standard MSI that installs the standard x86 registry entries on a 32 bit machine that same MSI will automatically be redirected to Wow6432Node for a x64 machine and everything should work if that machine has a 32-bit office installed.
If you have a x64 machine with a 64-bit office than you need to force the installation of that registry outside of the Wow6432Node, i.e. directly under: HKLM/Software/Microsoft/Office/Outlook/Addins/myAddin
This can be done from a 32-bit MSI too, if you mark the registry MSI component as a 64-bit (don't know where this option is in IS but I am sure you can find it). This will force the OS to stop the redirection to Wow6432Node for those registry entries. And the MSI should also work on 32 bit machines, where this flag will be ignored.
However, you should know that marking the component as 64-bit in a 32 bit MSI package will trigger some ICE errors/warning.
These are located in HKLM/Software (64bit)/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin)
FYI, this is the 32 bit area of registry on a 64-bit machine, not the 64-bit one. Only 32 bit applications can read registry from this location.
Installation package msi with check conditional "if the workstation is 32 or 64 bit
I need to make an installation package: which checks if the workstation is 32 or 64 bits and by finding. Next, if it is 32 go to Share\Path\ and run the run.exe, and if it is 64 bits, go to Share\path and run the run.exe
I could do this in a *.bat, separate do 32.bat and 64.bat, but will be better to have one .msi with two conditional check, also I need to do this in Visual Studio or another language that would give me a .msi, so I can send the .msi by sccm to my windows envirionment.
Could anyone help me with the code, please?
Thank you!!!
You could build 2 installers one for 32bit, one for 64bit and create a SCCM application adding both those installers as deployment types.
Then for each deployment set the requirements to the operating system types that match.
Then you can deploy them both to the same collection and they will only run on the correct versions. (I am assuming you have one large collection you don't want to break down to x86 and x64 yourself) The others will report back as requirements not met.
Also if you are wanting this for an application catalogue deployment or user deployment same principles will apply. If they are on a 32bit PC the 64bit will not allow the install to start. (Quite possibly wont show on the list of available software)
I am upgrade my 32 bit sample Voip application to 64 bit. After upgrade my application .exe file give a problem:
The application was unable to start correctly (0xc000007b)
My PC is 64 bit. and i build it in 64 bit
I realize this is probably late for you, but for anybody looking at this question, the problem is that you have a mixture of 32-bit and 64-bit components (DLLs) that are loaded at start-up. Since your app is built as 64-bit, you probably still have some 32-bit DLLs that the system attempts to load in the process and fails (since 32-bit modules cannot be loaded in a 64-bit process).
Currently I have a set of web applications that need to be installed (using IIS). They can only run in 32-bit mode so requires IIS to be set to run 32-bit apps. The steps that we've taken to do this work for server 2003 64-bit, and 2008 64-bit, but does not work on server 2008 R2 64-bit. I've spent many hours on this and I'm stumped.
The following are the steps performed to get the web apps installed:
1. Set "enable32BitAppOnWin64" app to true
2. Uninstall old ASP.NET stuff using 32-bit version of aspnet_regiis.exe: "aspnet_regiis -ua"
3. Install ASP.NET stuff using 32-bit version of aspnet_regiis.exe: "aspnet_regiis -i -enable"
As mentioned before, the above works fine on server 2003 64-bit and server 2008 64-bit, just not server 2008 R2 64-bit. Steps 2 and 3 give me the error: "Operation failed with 0x8007000B. An attempt was made to load a program with an incorrect format". After some searching, this is something to do with me running 32-bit application (aspnet_regiis) with IIS which is a 64-bit app. Step one has worked, as the flag has been set in the IIS GUI.
Would really appreciate it if someone could tell me where I'm going wrong, and why this doesn't work for 2008 R2.
Thanks
I know its a late post, but what I ended up having to do was run aspnet_regiis on the Framework64 folder and selecting the "Enable 32-bit Applications" on the application pool I was using and my sites came up.
In Vista and higher OS's ASP.NET is part of the OS and needs to be installed. You can install ASP.NET from the add windows features under Web Server.
The v4.0 version should work fine from both 32 and 64 bit folders.
Check for your Windows version.
If its a Windows 32 bit try running 'aspnet_regiis -i' from
C:\Windows\Microsoft.Net\Framework\v2.0.52707 folder
Or If its a 64 bit run it from
C:\Windows\Microsoft.Net\Framework64\v2.0.52707 folder