How can i solve the next problem that i have. Im using WCF and it reference a COM.
Creating an instance of the COM component with CLSID {...} from the IClassFactory failed due to the following error: fffffdf8f Exception from HRESULT:0XFFFFFDF8F
Obviously the CLSID that appears is my COM. My COM is compiled in Power Builder 11.5.
It appears in production environment after a long time of using but at the beginning of the day it work perfectly.
Do you think I should use System.Runtime.InteropServices.Marshal.FinalReleaseComObject(COM)?
Related
As you can see I checked for appointmentItem != null and rtfBody.Length != 0
although the call to appointmentItem.GetInspector throws a System.AccessVioloationException.
This happens when I run my Outlook addon via VisualStudio for a longer time (several hours) and then close Outlook.
My idea is that this is caused by the fact that Outlook is already shutting down, thus the AppointmentItem still exists but some COM related things are out of order. But this is only a vague guess.
Do you have any idea why this happens and how to avoid this?
Furthermore I already added a try/catch like:
catch (Exception ex)
{
log.Info(ex.Message);
return 0;
}
But the exception does not get caught. So I need to additionally catch SystemExceptions explicitly I understand, right?
This happens when I run my Outlook addon via VisualStudio for a longer time (several hours) and then close Outlook.
The common language runtime exposes COM objects through a proxy called the runtime callable wrapper (RCW). Although the RCW appears to be an ordinary object to .NET clients, its primary function is to marshal calls between a .NET client and a COM object. So, if the COM server doesn't exist (Outlook is closed) your calls to the RCW don't make any sense.
By default, starting from .NET 4.0, the common language runtime (CLR) does not deliver these exceptions to managed code, and the try/catch blocks (and other exception-handling clauses) are not invoked for them. If you are absolutely sure that you want to maintain your handling of these exceptions, you must apply the HandleProcessCorruptedStateExceptionsAttribute attribute to the method whose exception-handling clauses you want to execute. The CLR delivers the corrupted process state exception to applicable exception clauses only in methods that have both the HandleProcessCorruptedStateExceptionsAttribute and SecurityCriticalAttribute attributes.
You can also add the <legacyCorruptedStateExceptionsPolicy> element to your application's configuration file. This will ensure that corrupted state exceptions are delivered to your exception handlers without the HandleProcessCorruptedStateExceptionsAttribute or SecurityCriticalAttribute attribute. This configuration element has no effect on applications that were compiled in versions previous to the .NET Framework 4 but are running in the .NET Framework 4 or later; corrupted state exceptions will continue to be delivered for those applications. The HandleProcessCorruptedStateExceptionsAttribute attribute is ignored when it is encountered in partially trusted or transparent code, because a trusted host should not allow an untrusted add-in to catch and ignore these serious exceptions.
For more information about corrupted process state exceptions, see the entry Handling Corrupted State Exceptions in the CLR Inside blog.
You can also handle the following events of the AppDomain class:
AppDomain.UnhandledException is fired when an exception is not caught. Starting with the .NET Framework 4, this event is not raised for exceptions that corrupt the state of the process, such as stack overflows or access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.
AppDomain.FirstChanceException is fired when an exception is thrown in managed code, before the runtime searches the call stack for an exception handler in the application domain.
We moved to .net 4 and the work with exchange doesnt work anymore.
I'm using interop.cdo dll and when doing sessionclass I'm getting an exception -
retrieving the com class factory for component with CLSID faile due to the following error: class not registered.
Is there a way to fix this with this dll or should I replace all the work with exchange?
If I do - what is the best way? I cant seem to find information about it.
Thanks
I need to know CLSID of COM object which I just ran via CreateObject("xxx.xxx") how can I get it?
TIA!
Rafal
I don't think you can get that information directly from VB itself (e.g., as a side-effect or secondary result of calling CreateObject), but you can read the registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xxx.xxx and then look at its CLSID key.
We are adapting our client side relatively complicated application (ActiveX / .net / Delphi / C++ / COM ) to use SxS to achieve non admin deployment and isolation from older versions of our product.
We were able to achieve this goal for almost all our in proc components such as our .net ui, Delphi ui, and the COM servers we use in proc by composing a manifest file which described all the libraries used by our process, with no registration on the client of any of the components (almost).
And here comes the almost part:
At the moment, our application invokes (from it's c++ portion) an out of proc ActiveX server (Delphi ActiveX EXE), which in turn itself invokes another set of out of proc ActiveX servers (third party plugins, any thing goes here, Delphi, C++, any thing as long as it's out of proc ActiveX EXE and implements our interfaces).
As we know SxS does not support out of proc ActiveX servers. And we can't use these objects as in proc com servers in our main process because that would require a major rewrite of our application and even worst, a break of our public facing API which is used by third party tools and vendors, an api break which we can't allow.
We have stumbled on this article which describes how IHTMLDocument2 can be extracted from an Internet Explorer window running in a separate process. Which made us think of this approach:
We would create a secondary satellite application / process which will run the ActiveX as in process server.
Then we will use LresultFromObject and ObjectFromLresult to transfer a reference of the ActiveX object from the satellite application to the main application process. The satellite application will have it's own manifest file which will allow it to run in SxS mode.
Same approach will be taken to communicate between this Delphi ActiveX EXE and the third party AciveX EXE Plugins
There is an alternative solution, which for the moment we do not prefer over the proposed solution above which is to use .net remoting and .net com proxy classes to open the communication channel between the two processes, by translating the com request to .net remoting, and back to com on the second process.
So here comes the question:
What do you think about this approach ?
Do you see a better solution to the problem ?
It is possible to do. What is needed:
An application needs to start a server itself rather than relying on COM to do it. You don't need the extra indirection provided by the registry, just use CreateProcess().
A server should register its class factories in its main() method with CoRegisterClassObject().
Important: the CLSID it uses for each factory should be altered to be unique for each service instance. This ensures that the client connects to the correct server. I simply XOR the process ID with a class factory CLSID. The client knows the process ID as well so can make the same alteration.
The application should call CoCreateInstance() in a loop with a Sleep() call to wait for the object factory to appear. Don't declare failure until at least 60 seconds have passed (that bit me).
Both the application and the server need a manifest that contains a <file> element for each proxy/stub DLL and <comInterfaceExternProxyStub> elements for each interface that is remoted.
Alex,
nobugz is right, you can access the Running Object Table to create an instance of a COM Object from a currently running process of your Delphi automation exe.
However I have found a big issue that I cant explain. I can only access the object via the variant dispatch method when working this way.
Basically if my Active X exe is not registered, I get an "Interface Not Supported" error if I try to instance the object through interfaces for example:
WebUpdate : IAutomation;
WebUpdate := CoAutomation.Create; <-- Wont Work Error
WebUpdate : Variant;
WebUpdate := CreateOleObject('WebUpdate.Automation'); <-- Works Fine
If I register the active x exe using regserver the problem goes away!!
Go Figure!
I'm making some archeology, dealing with COM+
I managed to enlist a simple COM dll as a COM+ component, so far so good.
So I've got this 'foobar' com+ component, with it's interface, and the method I'd like to call.
My question is then rally simple: how am I supposed to make a call to this component?
Any .NET or VB6 answer is accepted (I have to check the component is OK, don't care about the client)
Thanks
Edit (06/03/09): Well, I'm confused. so as to work properly, my COM+ component needs it's dll to be registered. Why not? But then, how to be sure I'm making a COM+ call, and not a COM one?
Simplest VB.NET code snippet possible:
Dim myCom As Object
myCom = CreateObject("MyCom.ProgId")
myCom.Method(parms)
You need to replace "MyCom.ProgId" with the actual ProgId of your component - you can get this from the General tab of the properties of the component in the Component Services admin tool (sounds like you've already got a grasp of that)
myCom.Method(parms)
is simply a place holder for whatever method you want to invoke, with the parameters that method takes.
Here's a link to some examples of the VB.NET syntax:
http://msdn.microsoft.com/library/de...eateObject.asp
http://www.samspublishing.com/articl...le.asp?p=25857
http://msdn.microsoft.com/library/en...asp?frame=true
If all you are wanting is to check the component responds when called then use a quick VBScript rather than building something in VB6/VB.NET.
Dim o : Set o = CreateObject("Lib.Class")
o.YourMethod "someParam"
Watch your COM+ app in Component Services to see if the class requested spins up.
Adam's code in VB6 is similar:
Dim myCom As Object
Set myCom = CreateObject("MyCom.ProgId")
myCom.Method(parms
This example is late bound and carries with it some performance penalty.
You could call your method in an early bound manner, which avoids the penalty. In either VB6 or VB.NET, just add the COM+ dll to your references and you can call the object in this manner:
VB6
dim myCom as MyCom.ProgId
set myCom = new MyCom.ProgId
myCom.Method
VB.NET
dim myCom as new MyCom.ProgId
myCom.Method(...)
When you want to use COM+ for RMI then use this
Dim o As Object
Set o = CreateObject("Lib.Class", "MYSERVER")
where MYSERVER is the machine name where COM+ application is created and your DLL registered. Subsequently
o.YourMethod "someParam"
will be invoked remotely. If you are using only automation compatible interfaces, COM+ will successfully create a proxy for the RMI. Otherwise you'll need to provide the typelib on the client machine. This can be a separate TLB or the DLL itself.