Example of Cold Fusion 9 using a COM object?

[Guest]

We're not able to get COM of .NET objects working with Cold Fusion 9 and a third-party application. The vendor for the 3rd-party app has done some testing with their COM objects, as well as unrelated COM objects and they can't get any of them to work. This also matches our experience. Their hypothesis is that Cold Fusion 9 won't work with any COM objects. This seems surprising to me and I suspect that we are all implementing them incorrectly.

Can somebody provide an example implementation of CF9 with a COM (or .NET) object that we can test (preferably an implementation that is already tested to work). That will help us troubleshoot the source of the problem.

Our systems is Window 2008 server 64-bit. I don't know if the vendor is on the same O/S.

[-__cfSearching__-]

Like with CF8, the 64bit version does not support COM.

http://www.adobe.com/devnet/coldfusion/articles/64_bit.html

http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:61834

[Guest]

Thanks for the information and references!

Is there a best practice for these circumstances? I see in the referenced information the possiblity of using 32-bit .NET and/or DCOM. I'm not the programmer for this so please excuse any uninformed statements.

We want to use CF9 on 64-bit Windows 2008 Server to display ActivePDF documents. Can somebody recommend how we can approach this? Meanwhile, I'll pass this on to the developers involved to see if the answer is evident to them from the referenced discussion.

[-__cfSearching__-]

A brief search suggests ActivePDF offers a .net wrapper. You might try using that instead.

    http://www.activepdf.com/corporate/news/pressreleases/NetRelease.cfm

   NetRelease.cfm

Hey.. the ActivePDF site runs CF. Nice 😉

Message was edited by: -==cfSearching==-

[nickadel]

We too are experiencing the same issue with COM on 64-bit ColdFusion install on Win 2008 R2 (64-bit).  We've even tried connecting to COM through a Java proxy generated by J-Integra's 'com2java' utility (mapped via 'neo-comobjmap.xml') and still no luck.  Can someone at Adobe please give us a viable solution or at least explain as to why this is not being supported/fixed?  Going back to a 32-bit OS just doesn't seem like a good option for us.  Any help/answers would be greatly appreciated!  Thanks!

[-__cfSearching__-]

(These are user forums, so you will not get answers from adobe employees here.)

From what I understand it is due to jvm limitations.

       http://forums.adobe.com/message/4268918

[Owainnorth]

The solution is to do away with using COM objects; it's an old technology so no-one's bothering to put the hours into supporting it. In these days of not only .NET assemblies for Windows but also SOAP and webservices, there's not really much need for such a clunky old technology.

If you really rely on a COM object, I'd suggest looking into alternatives if there are any.

[nickadel]

Okay, got it.  Thanks for the reply guys.  In a perfect world, this particular COM object we're relying on would not exist, but unfortunately, I have to make it work.  I had no choice but to use CFEXECUTE which calls a VB shell (cscript), then wrapped it in a web service component.  This hack, I can confirm, works.