Have a requirement, where I need to connect to installed Microsoft Outlook Application and perform the following tasks:
Create/Read/Update/Delete Outlook Calendar Events
Create/Read/Update/Delete Outlook Contacts
Need to sync these entities with the Electron JS Desktop app.
What I have tried so far:
Tried electron-edge-js/edge-js, but this couldn't detect
Microsoft Office Interop assemblies.
Tried installing Visual Studio Code and starting Electron.Net application. This has too many issues to work with. No .Net C#
expertise, Client App does not reload on change, difficult to develop
the project. Don't want to merge Angular Electron project just to
sync those entities. maintenance would be difficult.
Need guidelines on how could this be achieved from the Electron JS Desktop app itself and without the .Net/C# environment. Looking for a solution that will work with windows installed Outlook application, and also with OSX installed Outlook application.
NOTE: Do not confuse this with Office 365 APIs. This is an old Outlook native application that adds emails from the system and works with Outlook Data files(.pst, .olm, .ost).
The solution with https://github.com/agracio/electron-edge-js works fine for me.
In order to make Microsoft.Office.Interop.Outlook available you need to specify path to microsoft.office.interop.outlook.dll in the references array.
Related
I have Visual Studio 2012 professional edition, and i want to add a reference for "Microsoft Outlook 15.0 Object Library" inside my web project, but i can not find it inside the COM, here is a screen shot from my Visual Studio:-
so can anyone advice how i can add the "Microsoft Outlook 15.0 Object Library" to my visual studio 2012 ?
how i can add the "Microsoft Outlook 15.0 Object Library" to my visual studio 2012
Looks like you just need to install Outlook first.
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. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround you may consider using a low-level API on which Outlook is based on - Extended MAPI. Or just use any third-party wrappers around that API.
If you deal only with Exchange account you may also consider using EWS or Outlook REST API, see EWS Managed API, EWS, and web services in Exchange for more information.
Well, if Outlook is not installed, how can you expect its type library to be present? You can of course create the interop dll on a machine where Outlook is installed, but your code still won't run without Outlook being present.
Worse than that, Outlook (just like any Office app) cannot run in a service (such as IIS). You can use Extended MAPI (C++ or Delphi) to edit the OFT files, but doing that in C# is far from trivial. And you will still need to install Outlook to have the Extended MAPI system present. In C#, you can try to use Redemption (I am its author) - it still requires the MAPI system, but unlike OOM, its RDO family of objects can be used in a service. In your case, you can call RDOSession.GetMessageFromMsgFile (it works with both MSG and OFT files), modify the Subject property of the returned RDOMail object, then call RDOMail.Save.
I am trying to create excel files using interop library, but below is the error I get:
Creating an instance of the COM component with CLSID {00024500-0000-0000-
C000-000000000046} from the IClassFactory failed due to the following error: 8001010a
The message filter indicated that the application is busy.
(Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER)).
I looked into lots of resources out there on the net, which broadly can be categorized into following:
Interop libraries are specifically built for desktop applications, and using them in a server side web application such as wcf is highly not recommended.
Permission issues related to interactive user or DefaultAppPool.
so and and so forth.
Well, here's the caveat, I cannot change the server side application and everything works everywhere else. Few days ago, office 2016 got pushed on my machine from IT, and things stopped working (with above error) on my local machine. Now I can't go and change a legacy code, but see if I can fix the issues on my local to do further development.
Here's what I did, please note that everything was working on this machine (when office 2013 was there):
Got office 2016 Uninstalled, and re-installed office 2013, same issue, hence reverted back to office 2016. Currently MS-Office 2016 32 Bit is installed.
Verified permissions on various sections of security tab of Microsoft Excel Application, have added IIS AppPool\DefaultAppPool user, IIS_IUSRS, Interactive User with full control permission, (shouldn't the error be "Access denied", had permissions been wrong?)
Created a new sample web application, to quickly debug, ran it in all combinations of cpu platform i.e. x86, AnyCpu, x64 - same issue.
Interestingly enough, it works if I point my sample application to IIS Express instead of Local IIS.
Added latest version of interop assembly available (Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1000) - still same issue
Added Microsoft Office 16.0 Object Library (2.8) to the project - still same issue
It's an age old question and its probably better to get away with interop, but I wanted to understand what might be going wrong - all the direct results for the error above suggest implementing IMessageFilter or what not, but I cannot change server side code, below line should simply work as it used to few days ago:
Microsoft.Office.Interop.Excel.Application l_ExcelApp =
new Microsoft.Office.Interop.Excel.Application();
but it doesn't, so what changed? what might have gone wrong?
Also, if it helps - ApplicationID listed in dcomcnfg (/32) is : 00020812-0000-0000-C000-000000000046}, but error has a different one.
Where to look? I hope answer to this question can guide lost souls for ever about this issue.
I'd recommend using the Open XML SDK for dealing or generating open XML documents on the server-side, see Welcome to the Open XML SDK 2.5 for Office for more information. Or just use any third-party components designed for the server-side execution.
As you already noticed, the Considerations for server-side Automation of Office article states the following:
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.
Finally I was able to resolve my issue. Following works:
Web Application hosted in IIS, creating excel documents.
So it turns out, apart from the permissions, it is also very important that the application architecture should be similar i.e. my application was 64bit (running as Any CPU on 64bit OS). Whenever you run into such an issue, make sure following also (apart from setting right permissions to right user):
Make sure the architecture of the two applications i.e. (your own and excel) are in sync. One quick way to know whether your excel is 64bit or 32 bit is by looking into Task Manager running programs. If excel is listed as EXECEL.EXE*32 then your office is 32 bit.
When you install a new version of excel, make sure you completely remove previous versions (and not just uninstall, but also removal of dcomconfig office entries i.e. by deleting any registry entry you can find in regedit for the involved office applications guid, specially excel).
I made it work by removing Office 2016 completely as described in 2, afterwards installing Office 2013 and fixing Microsoft.Office.Core reference accordingly in my code.
Permissions that I assigned was following:
Application Identity - Interactive User
And inside Security tab, added IIS AppPool\DefaultAppPool user to all sections and gave full permission.
My app runs in ApplicationPoolIdentity inside IIS.
If doing all the above, still doesn't fix your problem, then God be with you, and more power to you for your journey towards open XML.
I am writing an application that do Excel 2013 Interop.
My first step was to add the reference using the add reference > com panel. But the build on my jenkins failed because Office is not installed on the server.
It is out of the question to install Office on the server but I looked for Office 2013 PIA (like suggested on this post and so many other on the internet), but I could not find it.
So I ended up installing the nuget package for it. It was fine except that it does not install the Microsoft.Office.Core dll required for example to add picture to a worksheet... And I need that feature...
Do you know where I can find the Microsoft.Office.Core.dll or the
Office 2013 PIA?
Or do you have any other solution that could do the trick without
rewriting all the code that currently works?
Recommend you to use OpenXml, which is easy-to-use and will not require you to install Office.
You could add agents (one or more) that are Windows machines with the necessary libraries installed, then configure the master node to only run builds that are specifically assigned to it.
Then you don't need to install the Excel 2013 development environment on your server, and your build environment will more closely represent the user environment.
Refer to How to set up new Jenkins slave (where "slave" is the out of favor term for an agent)
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. Read more about that in the Considerations for server-side Automation of Office article.
As a possible workaround you may consider using the Open XML SDK if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office. Or just any third-party component designed for the server-side execution (for example, Aspose).
I've created an office add in using Visual Studio 2015. The add in works perfectly with MSProject in debug mode.
I've published the add in following the instructions here. So far so good.
Now I'd like to release it to the Microsoft Windows Store. I've logged into the Seller Dashboard and I pretty much fall at the first hurdle.
It asks for the app package manifest file. TBH I'm not sure which file it wants exactly, so I tried
xxx.OfficeAddin.vsto file in the root of the "publish" directory
xxx.OfficeAddin.dll.manifest in the publish/Application Files/xxx.OfficeAddin_1_0_0_2 directory
xxx.OfficeAddin.vsto
also within the publish/Application Files/xxx.OfficeAddin_1_0_0_2
directory
I assume it wants No2 but it didn't work so I tried them all. None of them work and all result in the same error:
Your manifest does not reference any supported Office Add-in namespace. The most recent version is http://schemas.microsoft.com/office/appforoffice/1.1.Learn More
Googling this error in quotes returns nothing, without quote - a load of unrelated results.
I'm completely stumped now - has anyone managed to do this?
You cannot add VSTO desktop applications to the Windows store, but may be able to do so soon.
The Windows Store was designed for installing applications that would run in private sandboxes that would keep apps isolated (in case of issues) from your operating system and other applications. However, Desktop applications often have registry entries, dll dependencies, and other client-side requirements. Because the Windows Store cannot accommodate these OS-related and client-side requirements, desktop applications cannot currently be distributed via the Windows Store
Fortunately, Microsoft is finally addressing this issue. They are in the process of finalizing Project Centennial, which will allow one to convert desktop apps for distribution via the Windows Store. It does this by providing a separate registry for desktop apps and a way for dlls to function without hurting other applications.
As of this writing, Microsoft has withdrawn the preview version of their Project Centennial Desktop App Converter. I am hoping this is in preparation for releasing a stable version.
Will Project Centennial allow VSTO add-ins to be sold via the Windows Store? I am hopeful, but this is not certain. We should know more within the next couple of months, if not sooner.
Update: June 8, 2016
At Microsoft's dotnetConf 2016 John Sheehan stated that VSTO add-ins would not be supported in version 1 of Project Centennial. He added that plug-ins (his term) that leveraged other desktop technologies would be able to be converted by the Project Centennial Desktop App Converter some time after Project Centennial's initial release (now slated to be concurrent with Window 10's 1st anniversary release in July 2016). Mr. Sheehan did not elaborate on whether VSTO add-ins would specifically work with later versions of Project Centennial, but he did indicate that compatibility with software that leverages other desktop technologies is definitely on the Project Centennial road map.
I have build C# windows form application using visual studio witch is simple outlook plugin installer.
It does these steps:
generates GUID and stores it to windows registry (for logging purpose later in outlook plugin)
Downloads actual outluck install files
Launches outlook plugin installation
The problem is that I can run this setup if .net framework is not installed. Is there a way of checking is framework installed? Or maybe there is a way to convert this app to native windows application (without .net dependencies). Or maybe it is possible to include needed dll's only?
I have tried using mono mkbundle, but I am getting strange errors in windows like Program too big to fit into memory or something with wrong application architecture (x64 X86).
I have also found some commercial tools for that like .net fuze. So maybe there is free alternatives witch does something similar?
Or maybe this single file installer idea is wrong? Maybe I should use something different?