I am getting the below exception when using the AxDrawingControl from the dll AxInterop.Microsoft.Office.Interop.VisOcx.dll (v4.0.30319) in my application:
System.Runtime.InteropServices.COMException occurred
HResult=-2147221164
Message=Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
Source=System.Windows.Forms
ErrorCode=-2147221164
The stackTrace:
at System.Windows.Forms.UnsafeNativeMethods.CoCreateInstance(Guid& clsid, Object punkOuter, Int32 context, Guid& iid)
at System.Windows.Forms.AxHost.CreateWithoutLicense(Guid clsid)
at System.Windows.Forms.AxHost.CreateWithLicense(String license, Guid clsid)
at System.Windows.Forms.AxHost.CreateInstanceCore(Guid clsid)
at System.Windows.Forms.AxHost.CreateInstance()
at System.Windows.Forms.AxHost.GetOcxCreate()
at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state)
at System.Windows.Forms.AxHost.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.AxHost.EndInit()
at TestVisOcxAxDrawing.VisioTestForm.InitializeComponent() in C:\ TestVisio\TestVisOcxAxDrawing\VisioTestForm.Designer.cs:line 55
InnerException:
The application is configured as “Any CPU” in the Configuration Manager -> “Active Solution Platform”
The app is throwing the above error when it is executing as a 64bit application in Windows8 64bit OS.
Visio installation is Professional 2010, x86 version.
Here are my observations so far:
The visio drawing control loads fine when visio x64 version is installed.
It also works fine if the “Active Solution Platform” is changed to x86 version.
Unfortunately both the above work-arounds are not possible in my case as it is a click once application and the clients could be running on any version of windows with any Visio version installed.
Questions:
Can the application be configured as "Any CPU" and still support both visio 32 and 64 bit versions ?
Are there any alternatives/best practices to handle such scenarios ?
eg: releasing 32 and 64 versions of the app separately ?
Or is it possible to ship both 64 and 32 bit versions of the Visio dlls along with the app and switch between them when an error happens?
Steps to recreate
Create a new Windows form project in VS2010 on a machine with 64 bit Windows OS.
Configure the project as Any CPU in the Configuration Manager -> Active Solution Platform.
Right click on the toolbox and click Choose Items -> navigate to COM Components tab -> Check Microsoft Office Visio 14.0 Drawing Control.
The Visio drawing control will appear on the toolbox now.
Drag the Microsoft Office Visio 14.0 Drawing Control control into a form and press F5.
The Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)) error will throw up.
Thank you,
Regards,
Praveen
Related
We are using Crystal Reports XI R2 (11.5.3300.0) in existing (32 bits) applications. We are in the process of upgrading to Windows7 64 bits.
During our compatibility tests, we bump into an issue indicating the crystal reports runtime is not available. I'm leaving out the exception detail here, as it is in Dutch, but basically it is saying that the runtime is not installed correctly, and that I should install the distributable CRRedist*.msi.
The problem I'm having is that I can't seem to find that distributable. When I check on the support site, https://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=56787567, it refers to a bootstrapper in the Program Files folder. However, the indicated subfolder does not exist.
Anyone who has bumped into the same type of problems for this version of Crystal Reports (I'm aware of the fact that several versions have been released after this one)? Where can I find the redistributable?
Mind that our applications are compiled for x86, so I think that the x86 runtime should do the trick.
Thanks.
just a quick caveat to any answer for you, if performance is important you should know that the x86 dlls will be significantly slower under emulation in an x64 o/s
I know this is an old question, but it was something I ran into as well so I wanted to update it with my experience.
I was not able to locate a redistributable for 64 bit. Instead, I had to change the project I was compiling to target x86. By default the C# and VB projects have the property settings on the project set to AnyCPU. Change it to x86 and this problem goes away.
For VB.NET, right click on project and select properties, go to the compile tab. On VS 2012, you will find it on the Target CPU combo box on that screen. On VS 2008, you need to select "Advanced Compile Options..." and then you will find the Target CPU combo box.
For C#, right click on project and select properties, go to the Build tab and you will find it as "Platform target:" combo box.
My add-in targets Outlook 2007 and was built using C# with Visual Studio 2010. I have run into problems deploying this to different target machines by means of the SETUP.exe and "manifest" built by the Publish Wizard of Visual Studio.
My latest attempt to get this deployed to a target PC (i.e. one typical of other users where this will be deployed and lacking my development environment) gives strange problems:
the add-in installs OK (i.e. Setup had no complaints; program appears properly in Control Panel)
visiting Tools -> Trust Center -> Add-ins shows that my just-installed add-in is Inactive
clicking Go.. for the Manage COM Add-ins dialog & checking the box for mine then the Add.. button fails
a window looking like a browse dialog box titled "Add Add-in" comes up with "No items match your search" in the right-hand pane; at the bottom of this window is an empty textbox labeled "File name:" and a choice of "Executable Files" or "All files" for a file type. The add-in remains "inactive".
It is not clear to me what this dialog needs at this point to make it "active" (Load at Startup was part of the choices here).
NOTE:
The 2 projects in this solution were compiled for a "target framework" of .Net 3.5 resulting in references to DLLs such as Microsoft.Office.Tools.Outlook.V9.0 and his companions (I guess that is "VSTO 3.0 ??).
This solution launches Outlook properly on the development PC and the add-in is loaded successfully and runs as expected (against Outlook 2007 and/or Outlook 2010); so this seems related to deployement only.
Could there be a bug in the stuff built by the Setup wizard that comes with Visual Studio 2010? I read somewhere that the "manifest" can be "corrupt".
EDIT-UPDATE 3/31/2011:
I think I found the answer. I believe by using the "Publish Wizard" in VStudio which produces a SETUP.EXE, I was trying what is called "ClickOnce" deployment. Secondly, this addin for Outlook is NOT a "document level" addin but instead a "machine level" addin. Given these discoveries of better terminology, I found this at http://msdn.microsoft.com/en-us/vsto/ff937654.aspx:
"You can use ClickOnce to create and install self-updating applications with minimal user interaction. This has an automated mechanism for easily distributing updates to your application. However, ClickOnce is not capable of deploying components that require administrative privilege such as machine level add-ins. For solutions that require administrative privilege you can use Windows Installer to deploy a Visual Studio Tools for Office customization."
So, I will try to make a Windows Installer. Any confirmation would be appreciated.
I am confident the ClickOnce style of deployment will NOT work for my machine level add-in for Outlook 2007. Therefore, I am answering my own question by stating only that this requires a Windows installer (and setup) that can built with the properly chosen Visual Studio template.
The sad news is that in my testing of said installer .msi and associated setup.exe for the pre-requisites the install to my target machine went well but when I test the operation of the addin itself inside Outlook I get a terrible APPCRASH event in Outlook.exe:
Problem signature:
Problem Event Name: APPCRASH
Application Name: OUTLOOK.EXE
Application Version: 12.0.6550.5003
Application Timestamp: 4d10fbc4
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18215
Fault Module Timestamp: 49953395
Exception Code: e0434352
Exception Offset: 000442eb
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 1033
Additional information about the problem:
LCID: 1033
Brand: Office12Crash
skulcid: 1033
So the answer is that ClickOnce is not appropriate. The .msi appears to properly install the add-in but at runtime it blows sky high. Remember the addin works properly at runtime when launched via Visual Studio. Why does deployment have to be so damned difficult?
Please help. I have a web application that was built in VS2010 and we are using the CR plugin for 2010 and everything works perfect on our local machines. When we go to deploy the web application to Server 2008 the application runs fine until we try to get to a report. When we get to a report we receive...
Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' or one of its dependencies. The system cannot find the file specified.
We have installed the CR2010 runtimes and the file log4net.dll version 1.2.10.0 is in the GAC so we are not referencing it in the application. When we add it as a reference we get this error no matter where we are in the application, not just on the report pages. Please help!
I received the same error message after accidently installing the x86 version of the crystal reports redist on a x64 machine.
Installing the correct x64 redist fixed the problem - http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_redist_install_64bit_13_0.zip
We just ran into the same problem and it turned out to not (in our case) be the version of the Crystal Reports redist (we installed the 32 bit versions on our 64 bit machines. The way we were able to fix the problem was to
Navigate to your virtual directory Application Pool -> Advanced Settings -> Set Enable 32-Bit Applications to True
and changed the managed pipeline mode from Classic to Integrated. After that we no longer got errors of the missing log4net dll.
We also had the same issue with the 64-bit redistributable installed. In our case, we set the "Enable 32 Bit Applications" setting to FALSE in the advanced Application Pool properties and that resolved the issue.
If you have a x86 development machine and your web server is a 64-bit machine, you may be running into the problem discussed here:
http://social.msdn.microsoft.com/Forums/en-US/vscrystalreports/thread/546059a6-7179-4027-8f16-822ac6dc189a/
Visual Studio is automatically deploying a 32-bit log4net.dll into the 64-bit web server, even if you don't have it referenced in your project. Just delete the log4net.dll from your bin directory once deployment has finished because it's not actually required by the CR runtime to work.
For me I had a VB Application project and under Compile options, I had "Any CPU" selected for Target CPU and I also had the "Prefer 32-bit" checked. When the compiled app ran on a 64 bit machine, which only had the x64 runtime installed it could crash with this error, because it tried running as a 32 bit app and wanted the 32 bit runtime. Unchecking this option and recompiling made it work correctly.
Install Crystal Reports for Visual studio Runtime engine for .NET Framework 64 bit
Solved my problems.
I have 2 NLB 2008 R2 Servers, my IISs are configured to run in x32.
In one server I have installed x64 and x32 SAP redist and I have the error, in second server only the x32 and works.
To get the first server work I uninstalled all versions and reinstalled only x32, but the server start work only after a reboot.
Bye
In my case I had the error while developing with Visual Studio 2022. I did what the other answers here say, installed Runtime 64-bit, because my machine is 64 bit, and then:
(in Visual Studio) Project Debug Properties > Web > Servers > Change Bitness to x64 (using IIS Express)
I have developed an application level add-in for Outlook targeting Outlook 2010 and .NET 4 and I want to run it on Outlook 2007, which should not be a problem due to the new "no pia" feature of .NET 4 (see this blog post).
However, after deploying the add-in with my Windows Installer package (the same package works for Outlook 2010), the add-in does not get loaded correctly and its load behavior is set to 2.
The test machine has the following software installed (in the given order):
Microsoft Windows XP with Service Pack 2 (x86)
Microsoft Office 2007 Enterprise
Windows Installer 3.1
Microsoft Windows XP Service Pack 3 (x86)
Microsoft .NET Framework 4.0 (Extended)
Microsoft Visual Studio 2010 Tools for Office Runtime (x86)
The utility assemblies are included in my deployment location and the add-in is registered correctly (shows up in Outlook trust center and deployment manifest is also included). I do not reference any third party libraries.
The strange thing is that the CLR 4 is not even loaded into Outlook, which I can see through the Visual Studio 2010 Remote Debugger. When I create an test add-in on my development machine and throw an exception on add-in startup, the load behavior also gets set to 2 on startup (without debugging), but at least the CLR 4 gets loaded into the Outlook process. Has anyone ideas what (probably missing dependency) could cause the VSTO 2010 Runtime to not load .NET Framework 4? I have also tried reinstalling VSTO which caused no effect.
Best Regards,
Oliver Hanappi
I found the solution on the msdn forums. There is a problem when no clr 2 is installed. A hotfix is required in this case. For more details see http://social.msdn.microsoft.com/Forums/en/vsto/thread/d95cc828-fdb9-4622-bf09-291a25cea81b.
I have created a simple application of reading mail properties from a nsf file using Interop.Domino.dll, things works fine for 32 bit OS but when i attempt to run the same application under 64 bit OS i am unable to create LotusNotes Session , getting the COM Exception. Though i can run the same application on 64 bit by changing the plaform to "x86" but if i change the platform to "Any CPU" its not working.
I have few other dlls which are meanted for 64 bit machine so i need to keep the Platform to "Any CPU", but in this scenerio i am unable to register the Interop.Domino.dll
Is there any Solution to it.
Thanks and Regards,
Haseena
The Domino server api is available in x86 and x64 flavors, so you would need to build against the appropriate one. The client api is x86 only, and if you are linking to that, it would behave the way you describe.