ColdFusion 8 added .NET integration, making it possible for CFML code to invoke .NET classes locally or remotely. The feature obviously won’t appeal to all users, but for those in organizations using both ColdFusion and .NET it does open up some very interesting doors. I’ve posted examples of how to use .NET integration, and others have, too. But beyond snippets and examples, I’d love to hear from any of you using this functionality in production applications. Specifically I’d like to hear about how you are using this feature, I’d like for you to share your thoughts on what works and what does not, and I’d like any suggestions on where you’d like to see us take this integration as we plan and build CF9. Thanks!
Do You Use CF8 .NET Integration?
11 responses to “Do You Use CF8 .NET Integration?”
-
Hi Ben,
Our company has been using the .NET integration for a few months now. We needed to integrate with .NET web services using complex .NET objects and found it easier to write that code in .NET and drop an assembly on the webserver for ColdFusion to call.
It’s working like a charm for the most part. My biggest beef is the limitations on passing certain datatypes into a .NET assembly. I would love it if I could pass in a query object and have it pop out as a datatable on the other side. Then I could move a lot more of the logic out of .NET and back into ColdFusion for easier maintenance and troubleshooting.
One other beef is that I must use absolute paths for specifying the .NET assembly and it doesn’t seem to like paths that start with "\", as in a server name or IP address. My assembly is called from nine different servers and I’ve had to put it on each and every one. Makes configuration management and releases a bit of a pain.
Despite my complaints,it has been a very handy bit of functionality and has saved us a great deal of effort. Without it, we would have designed some kind of crazy system of pulleys and levers to make it work. -
We use it for several major components of our system. It is primarily used as a high-capacity link to our MSMQ-based aplication. We also use it for interfacing with some legacy systems that aren’t so easy to integrate using built-in funcitonality.
When you can get it to work, it works fantastically. Sometimes though, it just doesn’t like to play nice.
My biggest gripe is that the method resolver doesn’t work for complex methods and overloads. If you have a method with multiple overloads, but the same number of parameters in each function, it’s near impossible to get it to resolve the function name. This is especially true when some of the paremters are .NET objects.
Another gripe is 64 bit compatibillity. It has caused us a bunch of headaches trying to get some of our legacy .NET assemblies working with CF.
Assembly signing is also IMO a silly requirement.
Overall though, it’s great. You just have to be very careful about how you design your assemblies if you want them to play nice with CF. -
Hi Roland,
Could you please tell me more about assembly signing? We don’t require the assembly to be signed and is not necessary at all. What error do you get when the assembly is not signed?
Rupesh -
Hi Bodie,
Its good to know that you find it useful.
– regarding converting query to datatable, we do it the other way around – i.e from datatable to queryobject as we thought that it will be the most common use case. We would definitely explore if query can be converted to datatable.
– Regarding path, in case you want to put the path of a remote server, you can map it to some drive on your machine, and you can use that path for assembly.
– In case you don’t want to copy the assemblies on each machine and if the assemblies don’t do anything machine specific, then you can also use the remote configuration. In this configuration, you will generate the proxy jars for the assembly using "JNBProxyGUI.exe" or "JnbProxy.exe" and use that in the assembly path. You can refer to the documentation for more details on it.
Rupesh -
Roland,
Could you also give us some examples where method resolver does not work. We are aware that method resolution CAN fail in some cases and we would always like to know where they fail so that we can fix them. You can send the example to me at "rukumar at adobe dot com".
Regarding 64 bit compatibility, it should be there in our next release. So you might have to wait till then.
Rupesh. -
I haven’t used the .Net features directly, but have needed to call a .Net webservice and use the resulting data. Frankly, I found it quite confusing. The documentation was next to worthless and the string returned from the cfinvoke command looked like random ascii characters.
I ended up using a chunk of code that someone blogged about to retrieve the complex dataset and view the data. I’d like to see a few of these common user needs built into the next CF iteration. While its nice to be able to manipulate the .Net system directly, in this case, I had a prebuilt webservice I wanted to access on another server in my company. It wasn’t worth having the author try and rewrite/tweak it if I could call it as-is. Unfortunately, without .Net understanding, I didn’t even know how to ask the author what to change. (solution below required no changes)
For those who need this function, it was written by Anthony Petruzzi and it takes a .Net dataset and converts it to a CF Structure of queries
http://www.cflib.org/udf/convertDotNetDataset
Load the 40 lines of code into your file before calling the cfinvoke command to the webservice.
<cfdump var="#convertDotNetDataset(return variable from cfinvoke command)#">
column name from result set = #convertDotNetDataset(return variable).table.columnname# -
I have not used .net integration with CF8, but upon reading your entry I immediately thought of a blog entry I read recently.
BlueDragon.NET versus ColdFusion 8: .NET Integration Performance
http://blog.newatlanta.com/index.cfm?mode=entry&entry=E0F13F54-6EBC-4B16-BA291F05D4842174
The blog author claims:
"CF8 .NET Integration feature is architecturally very similar to web services calls…. If you’re planning to use the CF8 .NET Integration feature, you’ll have to be very concerned about performance."
Is this a valid claim? -
I actually commented on that entry, but my comment is no longer there, odd.
Basically, Vince is correct. ColdFusion Java calls are native, .NET calls go via a bridge, so sure, .NET access will be slower than Java access. Same is try for BD, it can access Java far faster than it can .NET (assuming BD can actually do that). And the reverse is also try, BD.NET can call .NET code quickly, but would be much slower accessing Java. Anything native is going to be faster than access via a bridge, and that works both ways.
ColdFusion is Java based, and so Java interoperability is always going to be faster. But, for when you need .NET access, CF8 does provide that as an option.
— Ben -
Ben,
We decided to give it a try with the latest project we’re working on. Our approach was that we have a guy who is a .NET wiz, but we have him developing in a ColdFusion world, which is foreign to him.
Now, his code can take care of the data & business logic, allowing me to concentrate on the UI. It greatly reduces the amount of time I spend dealing with data, and allows him to develop in an environment in which he is more comfortable, thus more efficient and productive.
The results have been astounding! I see no reason why we woudn’t continue down this path.
Thanks for all you do!
Kevin -
Ben,
The .NET integration is probably my favorite feature in CF8. I hope Adobe continues to improve on the .NET features introduced in CF8.
David -
We call .net webservices to pass data back and forth between different applications. The front end of our web registration for classes is CF. This information is passed to a .net webservice that adds the user to the database and notifies staff…
The one main problem I see right now is that when I use Dreamweaver to add a webservice so I can use the frag and drop features, it does NOT maintain the capitalization that .net uses so I have to constantly go back and chack to make sure the capitalization is exactly like how .ent wants it, making it a pain in the rear.
Leave a Reply