Please answer the following:
1) Why migrate from Coldfusion to ASP.NET?
2) How's Coldfusion compared to ASP.NET?
Thanks

Its faster to develope in and quicker to learn. It can do almost anything that PHO, ASP.NET and JSP can do. In fact it CFMX is a Java application and you can also develope in JSP.

Coldfusion is much much faster to develop in; just have a look at some comparable code snippets on these forums and you'll see that what you can do in 5 lines in CF using almost plain english can take 20 or more lines of code in ASP and its variants. Now multiply that over a project!

Commercially I haven't found one thing that CF can't do that the others can BUT I have found lots that the others can't do EASILY that CF does in a flash... and don't even get me started on Flash integration....

IMHO CF rocks! and every time you get asked by a client to develop something in ASP.NET you should argue the pros of CF : robust, stable, development time, development costs (time=money). In some cases they will continue to bang the ASP.NET drum, mainly because "its our corporate policy" and not for any valid coding or stability reasons

good luck

Please kindly support what you said with links, articles, news, case studies, and/or benchmarks. Thanks much.

He can't, because he can't provide you with any.

First off, I have over seven years of ColdFusion experience.  And although it was good for it's time, .NET is simply better.  .NET is much more feature rich (async calls, REAL OO languages such as C#, strong typing, a decent IDE, pre-compilation, etc)

I have serious doubts about the robustness.  As for scalability, objects in the session scope in CF cannot be clustered.  That really restricts how you can scale CF.

Since version 6, CF has something called ColdFusion Components (CFCs) that is their lame implemention of OO.   No interfaces, no abstract classes, no method overloading, no constructors (!!), no event functionality and bizarre and needless variable scoping issues (among other issues) make them almost useless.

CF7 does have something called the Event Gateway that's basically an implementation of the Observer pattern.  Big deal.  One serious drawback to it is that it runs in the same context as your CF server, which means if your CF server is down, the Event Gateway is down.  Yipee.

Although CF is compiled _at runtime_ (i.e. when the page is first requested), there is no way for you as a developer to compile your application to check for errors at compile time, since there is no way to pre-compile a CF app.  This can significantly increase your maintenance time, since it is entirely possible for you to make and deploy changes that break during runtime.

Although CFQUERY is nice, there's no way to have transactions work on more than one database.  That's a serious limitation that's been around since time eternal with CF and has never been addressed.  There's also no way to close (or even explicitly open) a DB connection in CF, which can be a major scalability problem.

The biggest problem I find with CF is simply the level of developer that uses it.  Most are incredibly close-minded to the point of stupidity, which I have always found disturbing.  Trying to get some CF developers to even use consistent casing in their apps can be a chore.

There's also the problem with CF's memory usage.  Since there's no way for you to ask the underlying Java GC to dispose of objects you create, don't be surprised to see your CF server process take up gigs of memory even with light usage.

And, there's the IDE.  Dreamweaver is a piece of junk.   It's incredibly slow, a huge memory hog, crashes often and lacks even basic features like Intellisense.  The included help system is awful and is often incomplete and contains incorrect information.  Auto-formatting?  Forget it.

The effectiveness, scalability, or functionality of a project is not measured in lines of code.  Though yes it will require more lines of code in ASP.NET vs. CF the result is an elegant scalable product with clear seperation of the three tiers.  The code will be much more manageable and there will be no source code on the production server -- what a concept for those people who hardcode passwords in CFML pages.

vr, Rich

Most of the comments in this thread seem to smack of the Windows vs Unix religious wars I've seen elsewhere. Frankly, ColdFusion is much easier to code than .NET. Most of the negative comments about ColdFusion in this thread are very minor issues compared to item 1. Very minor issues.

Despite the overriding ease in coding ColdFusion, I'm still moving to .NET (I've been a hardcore ColdFusion developer since 2.0 was released). There are a couple strong reasons:

1. Allaire was basically a developer's company. Macromedia (and Adobe) are more designer oriented. It has made a real difference in how the product develops and how the company treats us. When we were Allaire partners, we used to get a lot of good stuff from the company and they listened a lot more to our feedback. We eventually dropped our Macromedia partnership because we weren't getting any benefit from the much more expensive membership.
2. I think this is a corellary to item 1, but ColdFusion seems to be fading to me. You can see it by browsing Monster.com or any of the other job sites. Not much demand for ColdFusion programmers - lots of people looking for .NET.
3. A lot of my clients are asking for .NET. It's not really a technical issue for them - mostly their corporations want to standardize and "nobody gets fired for choosing Microsoft" (their words not mine).
4. There are a lot of very useful and powerful .NET controls. I know that ColdFusion has the Developers Exchange (or whatever Macromedia/Adobe is calling it these days). But frankly, most of the stuff there is either very specialized or very trivial.

We'll be supporting all our many ColdFusion sites for years. But we'll probably do most of our new work in .NET.

By the way, there is an interesting product called BlueDragon that will allow you to use both languages in the same application. We've transitioned a few of our ColdFusion clients to BlueDragon servers.

Fair comments, Tom. I do appreciate your pointing out BlueDragon as an alternative, just as my colleague Vince did in a previous note in this thread.

But I do want to clarify that in that you're referring to the .NET edition of BlueDragon, someone may be confused by the reference to "BlueDragon servers". Just in case anyone might wonder, BlueDragon.NET is not a server, but instead just extends the .NET Framework (and IIS) to support processing CFML pages, natively on .NET. It does this in the way .NET is designed to be extended.

CFM pages are handed to the aspnet_isapi.dll (just like .aspx pages), an httpHandler is added to the machine.config or web.config (just as there is one for .aspx pages), and it points to the bluedragon.dll (a 3 meg file) stored either in the GAC or the bin of a web app.

CFML pages remain CFML, but it does indeed open tremendous doors of integration between CFML and .NET. I won't elaborate, as some may sense this is a sales pitch. It's not. It's just that there is simply no other solution for integrating CFML and .NET so seemlessly.

The BlueDragon documentation does the best job of explaining this in greater detail, particularly the manuals, "Deploying CFML on ASP.NET Servers" and "Integrating CFML on ASP.NET Servers" (split off from the former document as of our new 6.2.1 release about to come out).  

if you're finding that CF is running out of "elbow room" for you ("eg: explicitly opening/closing db connections), then feel free to create you own java connection classes and call them from CF. easy peasy.

some additional CF benefits:
 - runs on non-MS platforms (many flavours of unix/linux and now on Mac-OSX)
 - easy to write custom tags with name spaces (esp for custom UI controls).
 - QueriesOfQueries are much easier to use then ADO.NET's data tables/date relations, although QofQ aren't perfect (yet).
 - CF's ease in working with Java classes (CF is *almost* a macro language for Java)

some red herrings:
 - "better IDE" can sometimes be a draw-back. I'm battling VS2005 because it's doing too much for me and  it's a PITA to find out how to "double guess" it. Sure it's just a learning curve with the IDE but keeping things simple with Homesite 5.5 works too. It's a shame to have to be so dependant on an IDE to get it to do everything for you.. ...And lets not forget CFEclipse for integrated IDE's if you really want ot go down that path.
 - Clustering is definately an issue but there *are* workarounds most situations

just my 2c, nothing more

Shazam999, I realize you were responding to Barry's points and asking him for follow-up, but I will point out that as to your last comment about clustering and CFCs (as well as "creating enterprise apps that scale and have failover"), I'll repeat that BlueDragon.NET solves those problems.

I'm not trying to pursuade you to go back to CFML, but for those who are there and want the enterprise benefits that underlie .NET, you can get them without having to rewrite the CFML to ASP.NET.

As for "how to cluster CFCs", that again is a unique benefit of BlueDragon. Our CFCs are fully serializable (unlike CFMX) and therefore can be persisted and replicated. Hope that's helpful.

As you say, there is certainly testing needed if one wants to leverage the platform benefits of .NET by moving such legacy CFML to BlueDragon.NET. Still, it's a substantially smaller commitment of time than completely rewriting the CFML to ASP.NET.

Not denying that there are times when "throwing the baby with the bathwater" is justified, but for many shops, that just too great a challenge. Not to mention the cost/time to retrain (or replace) their CFML folks, and all the while continue to respond to ongoing customer requests. BlueDragon.NET definitely has its place.

Finally, as for the lack of CFC serialization in CFMX, I can't speak to Macromedia/Adobe's failure to respond to this need. I can only say that New Atlanta has had it in BlueDragon for some time. That's why BlueDragon exists: to solve problems for CFML developers.

And the deployment of CFML onto .NET, not to mention the many doors of powerful integration possible, is perhaps the most compelling benefit most see. As a seeming .NET fan, Shazaam, I hope you can see that we're doing our part to bring CFML folks into all the glory of .NET. We're just permitting to do it at their own pace and leaving them options for how to make it happen. It's worked for many shops, including the largest CFML site in the NET (and one of the top 5 most heavily trafficed sites in terms of page views), Myspace.com. I won't elaborate here, but it's been discussed elsewhere.

Shazaam, it seems your pitting us against each other and I never intended that. I'm sorry if that somehow happened. We're certainly not looking to turn .NET folks back to CFML. We solve a problem, we do it well, and to be honest full compatibility isn't really that significant to those with more challenging problems. Even so, I'm happy to point out that one loses only 4 tags from CFMX 6.1 (and again, if someone's happily on CFMX 7 then they have no need to consider us.) All that is discussed on our web site, in docs, faqs, our mailing list, etc.

I'll just say that if anyone reading this is interested in hearing more, including helpful and positive responses to the objections he's raised or any you may have yourself, I'm happy to help. charlie at newatlanta.com.

We can provide many glowing references from many other impressive organizations benefiting from BD.NET, and as a company with 12,000 customers across our 3 product lines, I can promise that our financial viability isn't something you need to question.