I have developed one trading application using VB6. In that, I have used Excel application object as below (Excel.Application).
Set xl = New Excel.Application
Set xlwbook = xl.Workbooks.Add
Dim xlsheet As Worksheet
Set xlsheet = xlwbook.Sheets.Item(1)
And, I have created the installer for that VB6's exe using Advanced Installer with prerequisites as Office 2010 Primary Interop Assemblies points to - o2010pia.msi (To enable the option to access Excel.Application).
I am unable to run installed application even installed the Office 2010 Primary Interop Assemblies. It throws Object Required error.
Note: I have googled regarding this, many of them suggested their solution for C# and/or VB .Net environment. I want it for VB6 environment.
Please help me to resolve this? Thanks in advance.
I'll summarize the comment thread as an answer. The OP has written a VB6 application that uses COM to create Excel spreadsheets. He was including the Office interop assemblies as part of his install but his code to create spreadsheets wasn't working. The reason for this is that Office was not installed on the end user computer.
The Office Interop Assemblies only give .NET applications an interface through which they can talk to the COM interface of an installed MS Office application, they don't provide Office functionality. In the OP's case he wouldn't need them as VB6 can talk directly to the COM interface of MS Office.
The OP either needs to install Office on his end user computers or generate his spreadsheets in a different way, maybe as a CSV.
Related
I am developing a COM object that implements the excel RTD interface using .NET c#. It is a x64 bit project and office is also 64bit.
The 64bit RTD COM object works just fine in Office 2016 (also 64bit).
I can register the COM object at the CURRENT user level and Office 2016 loads it just fine. Machine level registry works just fine too.
However, when using office 365 64bit version. I can only get it to work when registered at the HKLM level.
I would like to get it to work at the User level. Not everyone in the organization using it may have admin rights to their machine.
Is there some way to get it to work? Am I missing more registry settings or is there some policy that is blocking it at the user level?
NOTE: excel does recognize my COM object, but disables it. I cannot enable it at all. This all feels like some policy restriction new to office 365.
It looks like you didn't find the right hive in the windows registry for registering your RTD COM server on a machine with Office 365. See Add-ins for Office programs may be registered under the \Wow6432Node for possible routes.
I'd suggest investing your time for exploring capabilities of Add-in Express which allows creating installers for you. Also you may take a look at ExcelDNA.
I've seen posts from several years ago stating that automation wasn't supported in older click to run installations of Office, eg 2010. Can anyone tell me if this is still the case with Office 365?
For background, the reason I'm asking is I support some .NET desktop applications which use late-binding to automate Excel and Word. They've worked fine for all users until a recent client who has Office 365 Business click to run. On this PC (and this one only, so far) the app fails ("Cannot create ActiveX component") at the line:
Dim oExcel as Object = CreateObject("Excel.Application")
User claims Excel is definitely installed and working (and Registry key at /HKEY_CLASSES_ROOT/Excel.Application/Curver confirms 2016 is present.) Also CreateObject("Scripting.FileSystemObject") executes correctly, so it doesn't seem to be a scripting problem.
Thanks for any assistance!
I have a .net solution for converting word/excel to pdf developed in MS Visual Studio .Net 2003.I added references i.e., Microsoft.Office.Interop.Excel, Microsoft.Office.Interop.Word in my project. It is working fine in my local system where MS Office is installed but when I tried to execute in the server where MS Office is not installed, I face some Class ID errors 00024500-0000-0000-c000-000000000046 and 000209FF-0000-0000-c000-000000000046 with respect to Word and excel. So i told my client to install MS Office on server but he wants me to use Office runtime 2010 to convert MS office documents? So what is office runtime actually? Was it helpful in my case? Does MS Office installation is required if I am using VSTO?
I am new here. Kindly help.
Thanks,
Praveen.
There is no "Office runtime".
I added references i.e., Microsoft.Office.Interop.Excel, Microsoft.Office.Interop.Word in my project.
Interop assemblies are used to marshal your calls into unmanaged environment. There is no actual COM servers installed that may handle your calls (i.e. no endpoints).
Anyway, Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. You can read more about that in the Considerations for server-side Automation of Office article.
If you deal only with open XML documents you can use the Open XML SDK. See Welcome to the Open XML SDK 2.5 for Office for more information.
But if you need to deal with binary file formats you have to look for third-party components that are designed for the server-side execution.
From last couple of days I'm struggling with redistributable PIA 2010. Actually I have created one excel application locally, which uses 2007 PIA (I have also MS Office installed on my machine). This application was working fine, now I have installed the 2010 PIA and register it's Microsoft.Office.Interop.Excel dll then I have deleted then added this new dll in my earlier created excel application, but now application crashes on creation of excel object. i.e.
var app = new Application();
and below error is showing on browser.
Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.Office.Interop.Excel.Application'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{000208D5-0000-0000-C000-000000000046}' failed due to the following error: Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
Now, could anyone tell me what exactly wrong am I doing? Is this is the right approach to create excel application using only redistributable PIA 2010. If not, please help me out what is the correct approach to resolve this.
Redistributable PIAs are just a "complement" required by VS 2008 and older. The given MS Office version has to be installed on the target computer anyway. If you created an application relying on the Microsoft Excel Object of Office 2010 (version 14.0), it would only work on computers where Office 2010 is installed. If, on top of that, you built it by using VS 2008 or older, you would have also to install the corresponding PIA package.
I have an Excel UDF . It is written in C# and the automation addon has been packaged using the Visual Studio setu up project wizard. The addon loads in the list of automation addons available but the formula does not appear in the Insert function formula dialogue box.
I used Office 2003 and Visual Studio 2008 to build the addin. The client machine has .Net Framework 2.0 installed and does not have any installation of VS.
Should I have to enable the udf specifically somewhere ? This problem appears only when I am packaging the addon to distribute it to a client machine.
Thanks,
The fact that the COM add-in appears in the availale list of automation add-ins would imply that the COM add-in has been successfully registered on the target machine.
Could it be a Trust issue? You can check the level of trust your assembly has using the Microsoft .NET Framework Configuration: http://support.microsoft.com/kb/815147
I suspect you'll need full-trust.
I haven't built add-ins with COM for a while (I can list the alternatives if you like), so let me know if this doesn't fix it and I'll look into it further.