having trouble with getting my new Windows 7 laptop with 64 bit Office 2013, to integrate with Quickbooks 2013 from MSAccess 2013, using QBFC 11. Previous version that worked was Windows XP 32 bit, Access 2010 and QB 2013, with same QBFC11.
Using the new install, integration code fails immediately with "error 429 Active X component can't create object" when i try to create a session requestmsgset. I have searched a bunch to find non-specific answers which don't seem to apply or give me clues, does anyone have any idea how to fix this for Quickbooks?
thanks!
When installing Office 365 (the sister product to Office 2013), you are given the option to install 32-bit or 64-bit. But it recommends you use 32-bit, saying that most software is still operating with only 32-bit hooks and that a 64-bit version of Office will not work properly. I don't know that this is your difficulty, but that's what I would look at first.
Related
I have a VS2005 forms app that uses Crystal Reports (built on a Windows Server 2003 system). I can run the app in Windows 8.1, but when I try to open a report, I get an error saying it cannot find the Crystal Reports runtime. I've installed the CR2005_x86 runtime, and the C++2005 runtime for good measure.
I've also installed VS2005 on the Win 8.1 machine (with its SP1 and SP1 for Vista), can open/edit the reports within VS2005, and can build the app, but this too says it cannot find the CR runtime.
In both cases running with Admin priviledges.
Can anyone help? What am I missing or do I need to upgrade (eg to VS2012)?
Regards,
Tom
I have a Crystal Reports application that is hosted in IIS on a windows 2003 32 bit Server. The Crystal reports version in use is Crystal Reports XI Release 2 SP 2.
We are migrating our applications to Windows 2012 64 Bit Servers. I am not sure if this version will work support on 2012 server.
Can anyone please tell me if it will work on 2012? If not, is there any workaround?
While it's not supported, you may have luck with updating your Crystal to service pack 6.
See this page for links/details on doing so:
https://blogs.sap.com/2011/06/07/where-did-all-the-crystal-reports-xi-r1-and-r2-fixes-go/
We faced two scenarios using Windows 2012 64 bit Server and Crystal Reports 10.2.0.
In the first one, everything is working fine until now.
In a second one, I was working fine too, except when someone would try to save the report as an Excel file. It would crash the IIS ASP.Net process. Something on KERNEL32.dll, but I don't have the full message in English to post.
We tried to format the server and reinstall Windows 2012 Server, but it was useless.
We researched about it and all the references and possible solutions ended up at an orientation to install Crystal Reports 13.0.12.
We installed the newer version and everything is working fine.
Please note the the version numbers are a bit confusing. I always check the version number in windows "programs and resources".
Recently I upgrade my Office to Office 2013(64bit) on Win8.1(64bit). But the add-in dll files can not be registered by "regsvr32.exe {dll path}", in the same way I can create Excel Add-in by using delploytool for Office 2010(64bit).
Anybody know how to make Excel 2013 (64bit) work with the Excel Add-in generated by DEPLOYTOOL?
Cheers,
Cross
It is recommended to use Office 32bit even if you are using Windows 64bit, because of compatibility issues with add-ins. Office 32bit is fully supported with Windows 64bit
If the dlls are 32 bit then, I'm afraid, you're out of luck: a 32 bit dll cannot be loaded into a 64 bit process. That's an operating system level constraint.
Your only option is to downgrade your Microsoft Office to 32 bit. Then you get your 32 bit dlls back. But to register them, you need to use the regsvr32 executable in C:\Windows\SysWOW64\ (the normal place for the 32 bit compatibility programs). Then you can add references in the normal way.
Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).
Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)
Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.
Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?
Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.
Does the code use any Office 2007+ methods or classes? If not, are you sure you cannot use the 2003 PIAs in all cases? The later apps should be backward-compatible (supporting the same API) so the only reason you'd need an updated PIA is if you needed to access some feature added by 2007 or later, I think.
You may want to take a look at Add-in Express, which promises a one-for-all-versions installer, and is pretty easy to use.
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility
You cannot. You must create custom installer packager (setup bootstrapper).
Many years ago I used dotNetInstaller with HTML GUI builder, today WiX toolset would be better solution, I think.
Check how PIA .msi installers are constructed with Orca or .msi and .exe installers flow checking windows installer logs.
Based on registry checks, file checks, installed product checks, windows versions, office versions you can create conditions whether component should be installed or not.
Oh and I advise making plugin installers without prerequisites and installing them conditionally with your custom installer bootstrapper.
I have Visual Studio 2010 installed on my Windows XP development machine along with Office 2007 Professional and Office 2010 Professional. I am trying to develop several add-ins for Office 2007; however, I prefer to use Office 2010 on a day-to-day basis.
How do I set Visual Studio 2010 to install the add-in and open Word 2007 when I press debug? Currently, Word 2010 opens, but does not recognize the add-in. Unless I have to, I would like to keep Office 2010 installed.
I don't know the specific answer to your question, but I am running Office 2010 and still working on Office 2007 add-in development.
My solution to this problem has been virtual machines. I don't do any development work on my laptop's primary OS. I don't even have Visual Studio installed there, but I am running Office 2010 and really like it so far.
For development I've got dozens of different VMs with various configurations of OS and Office version and other 3rd party software that I need to integrate with. I'm currently using Windows 7 and the new version of Windows Virtual PC, but I started this practice when I was using Windows XP and Virtual PC 2007.
One benefit of this is that if something goes wrong on one of my VMs, it doesn't bring down my whole machine.
I also don't start from scratch each time I need a new VM. I've got base images with only the OS installed, as well as OS + Office and OS + Office + Visual Studio, but nothing else. That way, whenever I need a new VM, I just make a copy of the base image that's closest to what I need and go from there. The only limitation is that the base images can't be joined to a domain, but that's not a big deal for me.
I would encourage you to try this yourself. It works great.