I'm using the standard COM API of Outlook. It works perfectly well.
But since the release of Outlook 2016 in the Microsoft Store version, the COM is not accessible anymore.
Do you know any way to access it ?
I found the problem. Both things were happening, I was using a IUnknown instead of IDispatch, CoExInitialize was badly called, and my COM registration was messed up.
Related
My company has many old projects that are written in vb6. We have some reusable software components which are written in ATL/C++. We're now considering to rewrite our app with UWP but it seems that UWP apps do not support the old COM technology. I am researching if there is a way to implement a COM object which also supports UWP. I understand that porting our old components to UWP Components would definitely work. But we do not want to maintain two version of common components because we have shipped many old software and we still provide software support. Some of those software have been used by our customers for more than 10 years. It is impossible to upgrade all software we have shipped.
I have come up with few possible solutions:
Desktop Bridge
I have found a phrase called "Packaged COM" which can be used by UWP apps with Desktop Bridge. This article, COM Server and OLE Document support for the Desktop Bridge, gives an example of calling an exe COM server from an UWP app. It seems to be a good solution if it also supprts InProcessServer. I did found something suspicious, InProcessServer, but it turns out that it is for WinRT components.
I have also tried to add the COM reference to the UWP project. The code can successfully refer to the COM object. However, it doesn't work at runtime. The UWP app has its own registry hive, therefor is won't load the COM object which is registered to the system registry. I'm thinking that if I add the registration information to the private hive of the UWP app and pack the COM dll along with the app, this may work. Just couldn't find any example.
ATL/COM
Since we have implemented our business logic into COM objects. The most viable solution would be upgrading our COM object to support UWP applications. WinRT components still use COM technology but implement the new interface IInspectable, I assume that the old ATL based COM object can be modified to support the calling convention of UWP if it implements IInspectable interface. I just don't have any clue to do this.
WRL
I found an MSDN article, How to: Create a Classic COM Component Using WRL, talking about using WRL project template to implement classes COM object which can be used in Win32 application as well as UWP apps.
It says:
You can use the Windows Runtime C++ Template Library (WRL) to create basic classic COM components for use in desktop apps, in addition to using it for Universal Windows Platform (UWP) apps
But I soon realise that WRL project template is no longer supported by Microsoft. All the download links of the project template I found on the web are no longer available.
C++/WinRT
This technology seems to be the successor of WRL. It seems promising but unfortunately have not yet been released.
To clarify few things from #Peter Torr:
(1) Do you want your app / COM object to be "pure" UWP (runs on all
devices) or are you OK with fullTrust UWP (aka Desktop Bridge) that is
Desktop-only? And (2) are the COM objects only for use with the app
that ships them, or are they supposed to be used by other apps?
My company uses Windows platform to provide PC-based industrial automation services(both hardware and software). So the answer is yes, we are happy with fullTrust UWP. Our products will only run on desktop. We just want to embrace the new technology and leverage the great UI framework of UWP.
COM objects are for both new apps(UWP) and old software(some are vb6 based). We are happy with packaging COM objects with UWP apps and using system registered COM for old software as long as those COM objects are the same(built from the same code base).
We have a web service scenario in which the caller(wrote in Magik(r) programming language ) uses MSXML 6.0 to send a prepared SOAP xml to a webservice. the web method is written in C# using Visual studio 2012 and is published on IIS 7.5 (windows server 2012)
Problem is : the web method does not recieve the parameters, it is called with null arguments to be exact.
It also raises an exception "Object reference not set to an instance of an object" which shows the above situation.
Could this be a compatibility issue? Since all parts are Microsoft technologies it seems a little bit odd but here is some results that may help finding out the calprit.
The caller program works perfect with other .net webservices and sends parameters flawlessly
The caller also works fine with our webservice (in scenario) if the webservice has no parameters.
The webservice works fine with callers application if they are written in .net
The problem was in defining tempuri address. Which should be similar to wsdl but since I was creating the xml myself and sending it through msxml I set the tempuri address wrong which leaded to the problem.
Strange that Microsoft is that sensetive on tempuri, axis webservice don't!
I have an application developed in VB 6.0. I don't have access to its code. This application also exposes its functionality through certain API provided in its dlls. Is there a way for me to check what methods of the API the consumers of this application's API are calling across anywhere the API is deployed. I want a C# program to just sit in that target environment and intercept the calls made to that API and report it back to my service via a service. I wont be modifying the API or the code calling the API. Is this possible in C# or would I need to go with C++?
Update
Lets say for sake of simplicity, that its a simple VB application developed in VB 6 called SimpleAPP, and it has a button that displays records in a grid. It does this by calling a component CMPA.dll with a public method GetRecords(string ID) which returns an Array of records. I have another few applications called CustomerApp.exe and AnotherCustomerApp.exe which also have a reference to CMPA.dll and they both calls this same method to get the records. Now, I want to develop a program called Interceptor.exe that will actually sit in the environment where CustomerApp and AnotherCustomerApp is deployed and will log internally which of these two applications called that CMPA dll's public method GetRecords and also log what parameter it sent in and what results were retrieved.
I had to google to find the library that was on the tip of my tongue.
That googling turned up some interesting articles: a new to me 1999 Microsoft Research article called “Intercepting and Instrumenting COM Applications” and an Microsoft Systems Journal article from january 1999 that I do remember, “Building a Lightweight COM Interception Framework”.
The library you want is probably Microsoft Detours. I have only used it from C++, not from C#, and I have only used it for intercepting calls to Windows API functions, not COM methods, so I can’t guarantee that it’s well suited. But it's not exactly rocket science to interface these two languages, if needed.
If Detours doesn’t turn out to fill your needs, then look at the articles cited. Quite possibly they resulted in some framework you can use. And otherwise they have the information you need to build your own. You might then also check out if ParkPlace ever made what you want. There was once great interest in “cross concern“ functionality, and ParcPlace did some of the most interesting research, as I recall.
For IE microsoft provides COM to access it programatically. Is there any function to access Firefox from our Program
Mozilla Active X Control has largely compatible interface. (IWebBrowser/IWebBrowser2/...)
Of course Native XPCOM interfaces are a possibility for C++ programs.
Are you asking for a way to have your program that isn't running in Firefox to be able to access Firefox API's? If so, the answer is no.
I wrote a device controller (rs232) and it is being used successfully, however users want to view data and control the device (or perhaps communicate through my program) from Excel. I dismissed DDE as an option and found that RTD (IRtdServer) is probably a good start (though no way to send data back to the "server" from the real time data client).
I found these resources for the RTD part:
http://support.microsoft.com/?id=327215
and
http://support.microsoft.com/?id=327215
This is a multi-threaded app and I had already added the ability to have multiple listeners on the com port so that I could update multiple clients. I will add the COM interface to the EXE.
But what I need after that is some way of controlling my app/proxying commands to the device through my app from Excel.
What would be the best way to do that?
Perhaps another COM interface and calling it from VBA or something? I am not familiar with using scripting from Excel, so perhaps someone can provice sample code or links that show both the code for a COM object and the accompanying VB(A?) code?
Keep in mind that this is an unmanaged C++ application and it cannot be converted to managed or C# right now. Alternatives using C# are welcome as well, but that is a long-term rewrite.
Thanks
EDIT
I have an alternative to adding COM support into the existing EXE. I think it is more flexible to add a two-way communications (cross platform - maybe boost or corba or just straight IP based with my own message protocol)
A COM server (or two) can wrap that communications channel - whatever it is. This doesn;t really affect my question at all - I still would like to know the options for controlling an external EXE from Excel.
EDIT
Not having to roll out .NET to customers is also an big plus. many of these devices are on PCs that are pretty old and have perhaps NT or XP on them and I don't relish increasing my setup/install package from 700KB to the ridiculous .NET install size...
Option #1:
Create a small COM server - make sure its interfaces are suitable for scripting with the built Visual Basic engine in Excel. (e.g. use simple types and BSTRS).
Write Excel VB Macros to (1) add your own tool bar to excel and (2) call your COM server.
You can also add buttons and other UI elements to sheets and hook them them up to VB macros.
Option #2:
I realize that you do not want to use C# - but automating office, and talking to COM objects is really, really easy in C# with Visual Studio Tools for Office (VSTO). You shoul really look into this option - If done correctly, it shouldn't mean re-writing any of your existing code. Just use C# and VSTO as a bridge between Excel and your RTD server. As with VB, its straight froward to connect UI elements in Excel to C# and then to your RTD server.
Calling a COM object from VBA is straightforward. This SO Question and my answer give an example of how to create a COM object. Calling exposed methods is as you would expect:
object.ExposedMethod(optional params...);