We have a WinForms application written in C# that uses the AxAcroPDFLib.AxAcroPDF component to load and print a PDF file. Has been working without any problems in Windows XP. I have moved my development environment to Vista 64 bit and now the application will not run (on Vista 64) unless I remove the AxAcroPDF component. I get the following error when the application runs:
"System.Runtime.InteropServices.COMException:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))."
I have been advised on the Adobe Forums that the reason for the error is that they do not have a 64 bit version of the AxAcroPDF ActiveX control.
Is there some way around this problem? For example can I convert the 32bit ActiveX control to a 64bit control myself?
You can't convert Adobe's ActiveX control to 64bit yourself, but you can force your application to run in 32bit mode by setting the platform target to x86.
For instructions for your version of Visual Studio, see section 1.44 of Issues When Using Microsoft Visual Studio 2005
The .Net framework 1.1 is always targeting 32 bits CPUs while .Net framework 2.0 and above can target 32 bits or 64 bits according to the processorArchitecture property of the program manifest changed by the 'Platform Target' option of the Visual Studio IDE.
With the default option 'Any CPU', the IL code is compiled according to the platform but of course the COM call to the AxAcroPDF 32 bits component fails if the platform is 64 bits.
Just rebuild the EXE to target 32 bits platform only. This works fine with the WOW64 emulator in Vista 64 bits.
Use DLL isolation, works with every 32bit COM+ application. See more at:
http://support.microsoft.com/kb/281335
With this solution you can isolate your 32 bit COM+ application into a separate 32bit process.
64bit applications search installed COM+ objects at: HKLM\Software\Classes, but 32bit applications use HKLM\Software\WOW6432\Classes
Related
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.
i have developed an application (game) on visual studio 2012 (WFA) in C#, the application includes multithreading and graphics objects (pictureboxs, bit maps, labels...).
now the app runs great on the source pc (the computer it was developed on). but when i try to run it on my laptop it's run with very heavy flickering which is very weird.
source pc - windows 7 net framework 4.6 .
laptop - windows 10 net framework 4.6
*note - both are very strong machines who can run battlefield 4 with no problem.
what is going on??
You've got a software component issue - something that works correctly in 32 bit winDoze is broken in the 64 bit version. Try building your application as specifically 32 bit and run it on the 64 bit machine. Either it will complain about a missing (32 bit) driver (or other softwar component) or it will work correctly.
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).
I have inherited a classic ASP project and a VB6 Component (ActiveX .dll) that goes with it.
I would like to be able to debug this component by running it locally on my machine.
I have a Windows 7 Home Premium (64 bit) laptop.
I have setup IIS 7.5 locally (production is running IIS5), however, when I browse to the site (locally) I get:
Active Server Pages error '00000000'
Create object failed
?
An error occured while create object 'OBJECTNAME'
Microsoft VBScript runtime error '800a01ae'
Class does't support Automation: 'ID of object in global.asa
I'm not a server guy, so I don't have a lot of experience setting up IIS. I want to setup this project locally so I can step through the COM object using the debugger.
What do I need to do to get this running?
Just as an FYI :
In the global.asa I have the following:
<object runat="server" scope="session" id="ABC" progid="prjABC.clsABC"></object>
Then in the ASP I have the following call:
if ABC.propertyName = True then
...
It fails at that line.
Sounds like the application pool your site is running in is configured for 64-bit mode (the default).
Switch it to 32-bit by right clicking on the pool and choosing Advanced Settings:
Set Enable 32-Bit Applications to True.
You might also want to configure the Managed Pipeline Mode and set that to Classic, not all Classic ASP apps are happy running in Integrated mode.
If all you need to do is debug the component it may be easier writing a COM Application that uses this COM component. Especially if you have the source to the component you can launch your test application from your vb6 component project as your debug application.
Since it's VB6 though you may have to set up a XP virtual machine to be able to run visual studio 6.0 (I've never been able to get 6.0 working on windows 7). Either that or upgrade the component to visual studio 2010.
If you want to run 32 bit components in a 64 bit environment, you can do it. The trouble with setting IIS to allow running 32 bit components as described above is that you end up having all of iis running 32 bit - which if it's a webserver means the main app you're running is 32 bit so reduces the speed advantage of a 64 bit machine.
To run a 32 bit component in a 64 bit IIS, you need to put it in Component Services. Start->Run->"comexp.msc" runs component services. Then just expand down the tree until you find COM+ Applications, and create a new empty application (with all the defaults set as are). Then expand that application and right click on components and then "new">component. The install new component and select the DLLs. This should allow a 64 bit component to just use the 32 bit ones.
Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.
I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.
I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?
I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.
To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.
I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.
The solution was:
Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
Check the box "Show advanced build configurations" and click OK
Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
Now rebuild the project
Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.
More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?
Good luck
There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.