I know there are some nice new features in C# 4.0 but I can't, for the life of me, think of a compelling reason for either upgrading existing projects or for switching to new projects.
I've seen some posts where people have said that if their hosting service didn't provide .Net 4 that they'd find another provider as .Net 4 was pinicle to their direction <?>.
Now my boss is trying to get me to agree to switch all our production environments to C# 4 and to do it now.
So the question is has anyone either began using, or converted a project to, C# 4 for a compelling reason? Was there a feature that you just had to have that would make your life so much easier?
There are some cool new features in C# 4.0:
Dynamic member lookup
Covariant and contravariant generic type parameters
Optional ref Keyword when using COM
Optional parameters and named arguments
Indexed properties
In his release blog post Scott Guthrie goes into detail about the features of .NET 4 in general. Another great resource is a white paper at http://www.asp.net/learn/whitepapers/aspnet4. However, I'd doubt you are going to need one / any of these new features right away. As Scott Hanselman blogged:
there's a lot of stuff that's new and
added in .NET 4, but not in that
"overwhelming-I-need-to-relearn-everything"
way.
Whether or not you should upgrade is therefore dependent on a variety of other factors. Some reasons that spring to mind:
Standardizing your development environment on a single platform VS2010 over VS2008.
Size of the .NET Framework is substantially reduced
Speed improvements if you are a Visual Studio Tools for Office developer
An open dialogue with your manager seems appropriate to understand his reasoning for the upgrade. I'd argue that because it's shiny isn't a compelling reason.
As a reference this dated Stack Overflow question "Why not upgrade to the latest .net framework" provides the inverse to your question.
Quite frankly System.Collections.Concurrent has made developing multi-threaded applications a breeze.
The new and improved System.Linq.Expressions makes writing dynamically compiled code seem like child's play.
The new named parameters feature means I can have big constructors and not get confused as to what each parameter is. Immutable objects are just that much easier.
Surprisingly not mentioned:
PLINQ
Task Parallel Library
Is your question specific to C# 4.0, or .NET 4.0?
In C# 4.0 there are only a couple of really nice new features. Covariance/contravariance is not useful all the time, but when you run into a need for it, it can really save a lot of pain. Optional method parameters can reduce a lot of ugly method overrides, and make certain method calls a lot cleaner. If you're using COM or IronPython or any of a few similar frameworks, the dynamic keyword can also be a real lifesaver.
.NET 4.0 in general has a ton of really interesting features across a variety of frameworks. Foreign Key support in Linq to Entities, for example, is making life a lot easier for us. A lot of people are really excited about POCO support. They also added support for some of the LINQ methods (e.g. Distinct) that were previously missing from the Entity Framework.
So it will really all boil down to which frameworks you're using and how you're using them, and how expensive it will be for you to make the switch.
First, what is compelling to me may mean nothing to you. Having said that, I would upgrade Visual Studio if budget allows. In fact, personally I think there is a huge career risk in staying with a company that doesn't keep your tools up to date. You will fall behind in your knowledge of the field without access to the latest tools.
As for converting all your projects just to convert them it seems like folly to me. Putting aside all the extra work distribution (and upgrading the machines to have .NET 4), you have to consider the chance that you will have something go wrong. (And if you are like me some things must be called from 3rd party programs using .NET 3.5 making them unable to convert.)
My first rule would be that nothing is converted unless you are working on it anyway. But I would seriously look to convert anything that could use improvement from either parallel code, or COM interop.
I do have a compelling project that was converted. I had a long running web method being called. In the version that exists now, I return from the method without knowing the results. Instead I gave the user a way to check later. By moving to a parallel foreach loop this works much better and I can let the user know if there were any errors.
The same project is also being converted to use RIA services which have greatly improved and reducing the amount of my own code.
I upgraded for the same reason everyone else did.
...so I can put it on my resume :)
If you're starting a new project today, it's probably best to start it on 4.0, since down the road you will have to migrate it at some point anyways (assuming it stays around long enough, older versions of .net will simply stop being supported).
C# 4 implies other things.. depending on your project... WCF 4, WPF 4, ASP.NET 4, MVC 2, Entity Framework 2, etc.. So don't just look at C# as the reason to change, you also have to look at the whole stack. If there's still nothing compelling, then staying where you're at is probably a wise choice.
If you're doing WPF / Silverlight, I would definitely recommend upgrading to Visual Studio 2010 (I know, you can write .NET 4.0 code without an IDE, but that's an edge case if ever there were one).
The multi monitor support is nifty but buggy. I spend a lot of time trying to get windows to refresh.
In terms of language, the COM interop (as #Gvs mentioned) is also vastly improved with the dynamic datatype and optional parameters.
UPDATE: Multiple monitor support is pretty rock solid with VS 2010 SP1.
If you can get your boss to pop for the $10,000+ Visual Studio Ultimate Edition, IntelliTrace is a compelling reason to upgrade your environment and justification enough the for investment.
COM integration is much easier with the dynamic datatype, and optional parameters.
For me there are two things:
optional arguments -- because I am sick of polluting classes with X versions of the same method (overloading)
dynamic keyword -- because the expressiveness of generics in C# is a joke, this way I can at least "write what I mean" without hoops, of course with execution speed penalty
The more compact the code (i.e. if you express the idea without addition "oh, how to avoid limitation Y of the language"), the better, because the code is much easier to maintain and it is harder to make a stupid (or worse) mistake.
There are no compelling stability or security reasons to switch. Shouldn't that be your boss's concern?
Related
Migation of a VB6 application to .NET platform is almost like a rewrite, no matter it is VB.NET or C#. Do you think it will require more effort to do it in Java platform, when compared to .NET platform, since it is a rewrite anyway? Please share your thoughts!
No offence, but you are wrong. Porting to .Net is usually far easier than a rewrite.
Here's the official advice from Microsoft UK:
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
From a blog post by a Microsoft guy who consulted on rewrites:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
I recommend the following two steps in this order.
Write down the reasons for migration or rewriting. What benefits will it bring? The benefits might be just to keep the development team happy - that might even be a good enough reason, I don't know. Make sure you know, and your managers/users agree.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. It may be rewriting, but go into it with your eyes open.
In answer to your actual question: would a complete rewrite be easier in .Net or Java? That mainly depends on which one your team knows best. It also depends a little on whether the application interacts with COM, just like SLaks says.
The effort of rewriting a VB6 app is more than just a question of which language you're targetting. VB apps often rely on COM objects and certain VB-specific library methods which may not have equivalents in Java - but may have some portability in .NET.
Unless you are willing to abandon all of the dependences of the project, you may find .NET an easier target to re-write for, especially if you need to preserve some of the behavior of the existing application which derives from libraries or other dependencies.
Another consideration will be which platform your team is most familiar with - if you have a lot of Java expertise but little or no .NET expertise, then perhaps Java is a good choice for you.
There are tools available that will migrate from VB6 to VB .Net, including the one built into Visual Studio. This tool migrates VB6 to C#. Whatever tool you use, you will still need to do a lot of manual work on the code that the tool outputs, however this is likely to be less work than a complete java rewrite.
Depending on your existing application's architecture, and how well the code is structured, you may decide it is better to completely re-design and rewrite it anyway, in which case there may not be much to choose between .Net and java.
It is important to reduce not just the total effort during migration but also the cost of maintenance after migration. Many factors drive TCO, but all things being equal I think the .NET tools, community, framework, and C# language meet or beat Java in terms of developer productivity, operational managability, and performance -- assuming your are targeting windows OS.
I do not think ease of keeping COM should be the deciding factor either. In fact, I think migrating VB6 to .NET but keeping COM when you do not have to defeats a critical purpose of doing a VB6 migration in the first place: to reduce development costs and risks by moving to a well-supported and viable platform. I will tell you why:
Most of the popular COM libraries and
controls that were used with VB6 have
not evolved in many years; many of
the smaller vendors have disappeared
or if they are still supporting their
wares, they now also offer new and
improved .NET versions.
Living with old COM after migration
means living with additional
complexity in terms of debugging,
builds, and deployment. Also beware that COM
components do not really "speak" .NET
(i.e they do not use .NET types and
conventions) so their use with .NET usually
results in added complexity in the
coding and design.
There still are a few
hold-outs and exceptions to this rule
and a .NET replacement is not the
always best choice, but in general,
migration teams will be able to find
at least one .NET replacement option
for almost every COM component they use.
Taking the time to thoughtfully
evaluate, select and upgrade to one
of those options will pay off after
the migration.
You will not want to interop anything
that is VB6 you plan to migrate. Interoping your own code will lead to a longer,
complex transition and typically
requires back-tracking and
reworking/retesting already migrated
codes. Clearly this is not the most
efficient and understandable upgrade
path.
One more point about having to do "a lot of manual work on the output". The Great Migrations product is a new, programmable migration tool. It is designed to help migration teams incrementally improve the quality of generated code and thus reduce the manual work required to complete the migration project. This includes making the translations more correct, dealing with complex multi-VBP migrations, and also automating the restructuring of VB6/COM code to use .NET components. These features are particularly helpful if the VB6 codebase is very large, changing frequently, and being significantly re-engineered and cleaned up during the migration. This is an agile migration methodology we call the tool-assisted rewrite.
Disclaimer: I work for Great Migrations.
If the application uses COM, it will be far easier to rewrite it in .Net than in Java. Otherwise, it will probably be somewhat easier to port to .Net.
For a more specific answer, please provide more details about your application.
You could also use Jabaco it is a Java Bytecode compiler and it has it's own IDE and syntax very similar to VB6 (nearly the same).
You can find more information at:
http://www.jabaco.org/
http://www.jabaco.org/board/
use a migration tool, like ArtInSoft to just migrate it to .NET.
You can migrate the VB 6 application using the in built VS migration to VB.Net. Try to see if that helps you. If you are looking at migrating VB 6 to C# then I would also recommend what ScaleOvenStove user has recommended.
I am upgrading a Windows Client application that was earlier .NET 1.1. The previous developer handwrote many solutions that can be done automatically with the newer versions of .NET. Since I am relatively fresh to .NET and do not have the complete overview of the features I am asking here.
What is the most notable classes and syntax features provided in later .NET versions that is likely to swap out handwritten code with features from the library?
Biggest changes off the top of my head:
Use generic collections instead of ArrayList, Hashtable etc.
For C# 3.5, use LINQ instead of manually filtering/projecting
Use generic delegates instead of having to declare your own all the time
Use anonymous methods instead of creating a one line method used to create a delegate in one place
Use BackgroundWorker for WinForms background tasks
Generics is the most wide-reaching change in my view.
Personally, I would leave any 1.1 code that works fine when compiled with 2.0/3.5. Unless you have the time, anything you rewrite you'll have to test again, and you still may introduce new bugs that your testing can't find.
Things that I'd look to use for future versions though, would be generics and LINQ. Generics with .NET 2, and LINQ with .NET 3.5.
LINQ was a big leap. Might be possible to use that in some places (e.g. XML code). Also, generics may reduce the need for some classes.
Also be aware of and test for possible impact of breaking changes between the versions of the framework. A google search should reveal the top issues.
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved. So what functionality available in the .Net framework do you feel professional developers should avoid and why?
For example, .Net has a wizard for common user management functions. Is using this functionality considered appropriate for professional use or a beginner only?
One component/feature/class, etc per answer please so votes are specific to a single item.
Typed DataSets
ASP.NET *View Controls
ASP.NET *DataSource Controls
MS Ajax
jquery, and other js frameworks like prototype etc., are a more lightweight and flexible alternative. The MS Ajax controls may seem great initially, until you really need a custom behaviour out of the scope of the controls.
Microsoft themselves have recognised this to some extent in that jquery will be bundled with upcoming versions of visual studio, with intellisense support.
I think generally most controls/features that do a lot of work "behind the scenes" can cause a lot of trouble. No problem using a GridView if that layout is exactly what you want - but it very rarely is, and a Repeater is probably a better choice. UpdatePanels can save you lots of work if you want an ajaxy feel to your site, but compared with a jQuery AJAX call they - sorry to say so - suck. The user wizard you mention can be really useful during development, but if membership functionality is required in the project it should be built as an integrated part of it.
So in summary: Professional programmers should do the job themselves and write code that specifically satisfies their clients needs, and only take in ready made parts of the .Net Framework when that is in fact exactly what they need.
Thread.Abort
Here is an excellent article by Ian Griffiths about Why Thread.Abort is Evil and some better alternatives.
Remoting is generally a good one to avoid, at least if you're targeting 3.0 or above and can therefore easily host messaging endpoints in-process.
Linq To XML
XmlDocument/Xpath is easier to use, if you want strong typing to parse your document use xsd.exe or Xsd2Code.
EDIT
which one do you prefer ?
IEnumerable<XElement> partNos =
from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") *
(decimal) item.Element("USPrice") > 100
orderby (string)item.Element("PartNumber")
select item;
or, with XmlDocument and XPath
var nodes = myDocument.SelectNodes("//Item[USPrice * Quantity > 100]");
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved.
It's the "appears to target beginners" that's the real problem.
Typed data sets are a great example. VS provides a nice simple UI to functionality that should be used only by rank beginners building extremely simple demo applications and experienced professionals who understand every nuance of the ADO.NET object model and what typed data sets are actually doing. Nobody in between those two poles should touch it, because there's a good way to learn every nuance of the ADO.NET object model and typed data sets aren't it.
Or take LINQ. It's seductively easy to write LINQ code without having a good understanding of IEnumerable<T>. But it's not so easy to write maintainable LINQ code without that knowledge.
You can think of .NET like an onion with many layers. For example the .NET compact framework is a subset of full .NET. Further there are "extra" layers on top on .NET in the form of "Extensions" which are optional installs for new features which have not yet been made part of .NET proper. An example of this would be when Microsoft released ASP.NET 3.5 Extensions which has now been rolled into .NET 3.51.
Another way to think of .NET is as a set of "libraries" you can use. For example there are a set or routines to support RegEx. If you want or need regular expressions, then you use these functions, if not you can simply ignore them. SImilary functions for things like trigonometry or security.
So I guess it really boils down to what do you need for your application? If you are doing scientific programming you may well want the trig functions. A graphical app will require functions that a console application would not. Web apps probably do not need to use the clipboard functions etc.
I really don't think there are any bad APIs in .NET, just programmers who use them in inappropriate ways.
There is lots to avoid in the WinForms library.
Avoid DataBinding to most standard WinForms controls. There are many bugs in that area which will lead to lots of head scratching. Or at least that has been my experience. NumericUpDown is a good example of this buggy mess.
Also avoid the standard WinForms controls when dealing with large datasets. They do a lot of data copying and can't deal well with large datasets.
Avoid ListView in "Virtual" mode as it is full of bugs.
In general I just recommend staying away from WinForms. If you have the option go for WPF or at least buy a good, well supported (and hopefully less buggy) 3rd party forms library.
I have a VB5 (non .net) project that I would like to upgrade to a c# project. Has anyone have any suggestions on methods or free tools that are avalible to help me with this.
Thanks
Brad
You are better off with a straight rewrite.
What I would suggest is first convert the project to VB6. It'll be much easier to go forward from there. There are a number of tools to help you do this. There is VBMigration Partner and there is vbto. I've not tried either so YMMV.
If costs are a constraint you could try this: there is a wizard in Visual Studio that will attempt to upgrade VB6 to VB.NET. It's not 100% accurate and you WILL have to write code for things VB.NET does not support such as control arrays, etc. Once the code is in VB.NET you can use a tool like SharpDevelop to convert the VB.NET to C#. It'll be a bit tedious but i suppose all roads, no matter how convoluted, lead to Rome.
In case you were able to migrate it to VB6 you can use the code advisor to see how you can fix your project to be compatible to vb.net, then you can migrate to vb.net, in case it success, you can use this tool to convert it to c# or the Reflector.
I give it a chance of 1x10^(-100)% to work.
Good luck.
If you're about to convert VB5 to .NET (whether it's C# or even VB.NET) the fastest way is to restart from 0 your implementation so you can take full advantage of .NET Framework classes. I don't know if there are tools to do this conversion automatically.
It's rarely a good idea to do a strict conversion from one language to another, particularly when they are as different as VB5 and C#.
Theoretically, you could convert VB5 to VB6 and then VB6 to VB.NET and then VB.NET to C#, but that just sounds crazy to me as I type it.
C# is so much more powerful than VB5 that you wouldn't want to covert the code anyway. After all, it likely has a poor design due to VB's weak OO capabilities.
I'd instead recommend re-implementing the functionality you need in C# (or whatever other language you want to use).
I know there exist a conversion tools, not sure though if there are some for vb5.
However, i'd recommend performing a redesign of the project, taking advantage of the .net features unavaiable in vb5. Specially it would be good redesigning for a OO language.
Migrating VB5 to C# just to have .NET is never a good reason. I would prefer to have a good look at the assumptions and design decisions I made in the VB5 version, rethink them all, add new ideas, sketch the UI and improve it to look closer to a modern one.
Then it's a new project, I wouldn't even call it a rewrite, because so much would have changed.
I've migrated a small 1-tier VB6 application to C# and I will never do it again.
There are applications out there that do a rather good job migrating from VB6 to VB.Net.
//Magnus
I’ve done it in the past but don’t recommend it. Getting the project to work correctly after the ‘auto-migration’ was not worth the effort. I ended up rewriting the program and was better off because of it.
Having done this myself I talk about the issues involved here.
Basically as ocdecio you are looking at least a partial rewrite. You will likely need to refactor your forms to move as much code out of them as possible. You will also need to refactor any VB6 specific features to work behind a interface that you can reimplement in .NET. Notably the Graphics commands, and the Printer functions. Migration Tools are usually worthless for any serious project.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Has anyone ever written an application bigger than its .NET luggage?
People used to criticize VB6 for its 2 MB runtime but it rarely dwarfed the app it accompanied.
Today despite having Vista on my machine I had to download 35 MB of the 3.5 framework and reboot to then try out an app half that size.
When you factor in the decreased source code security I wonder why anyone would anyone develop a windows application in .NET rather than in a language that allowed for the building of native executables.
What is superior about .NET that outshadows these drawbacks when it comes to writing applications to run on Windows?
PEOPLE: Please note that this was written in February, 2009, and what is said was appropriate at that time - yelling at me in late 2012 (3+ years later) is meaningless. :-)
Delphi has some considerable advantages for Win32. Not that .NET apps are inherently bad, but try:
running a .NET app (any version) on Win95/ME, where .NET doesn't exist (AFAIK)
distributing any small ( < 1.5 MB) .NET app (yes, floppy drives still exist)
providing any .NET app on a system that has no Internet access (yes, they exist)
distributing your .NET apps in countries without widespread high bandwidth
keep people from seeing your source code without spending a ton of dough (Reflection, anyone?)
Garbage collection in .NET might be really nice, but anyone who knows anything about programming can also handle manual allocation/deallocation of memory easily with Delphi, and GC is available with reference-counted interfaces. Isn't one of the things that brought all of the non-programmers to proliferation the pseudo-GC of VB? IMO, GC is one of the things that makes .NET dangerous, in the same way VB was dangerous - it makes things too easy and allows people who really have no clue what they're doing to write software that ends up making a mess. (And, before I get flamed to death here, it's great for the people who do know what they're doing as well, and so was VB; I'm just not so sure that the advantage to the skilled outweights the hazards to us from the unskilled. )
Delphi Prism (AKA Rem Objects Oxygene, formerly Chrome) provides the GC version of Delphi that those who need it are looking for, along with ASP.NET and WPF/Silverlight/CE, with the readability (and lack of curly braces) of Delphi. For those (like me) for which Unicode support isn't a major factor, Delphi 2007 provides ASP.NET and VCL.NET, as well as native Win32 support. And, at a place like where I work, when workstations are only upgraded (at a minimum) every three years, and where we just got rid of the last Win95 machine because it wasn't a priority to upgrade, the .NET framework is an issue. (Especially with company proxy requirements only allowing Internet access to a handful of people, limiting bandwidth and download capabilities, and proper non-admin accounts with no USB devices allowed, all still running across a Netware network - no such thing as Windows Update, and never a virus so far because nothing gets in.)
I work some in .NET languages (C#, Delphi Prism), but the bread and butter both full-time and on the side, comes from Win32 and Delphi.
Okay, I doubt this will persuade you as you don't want to be persuaded, but here's my view of the advantages of .NET over older technologies. I'm not going to claim that every advantage applies to every language you mentioned in the question, or that .NET is perfect, but:
A managed environment catches common errors earlier and gives new opportunities:
Strong typing avoids treating one type as another improperly
Garbage collection largely removes memory management concerns (not totally, I'll readily admit)
"Segmentation fault" usually translates to "NullReferenceException" - but in a much easier to debug manner!
No chance of buffer overruns (aside from the potential for CLR bugs, of course) - that immediately removes a big security concern
A declarative security model and a well-designed runtime allows code to be run under a variety of trust levels
JITting allows the CLR to take advantage of running on a 64 bit machine with no recompilation necessary (other than for some interop situations)
Future processor developments can also be targeted by the JITter, giving improvements with no work on the part of the developer (including no need to rebuild or distribute multiple versions).
Reflection allows for all kinds of things which are either impossible or hard in unmanaged environments
A modern object-oriented framework:
Generics with execution time knowledge (as opposed to type erasure in Java)
Reasonable threading support, with a new set of primitives (Parallel Extensions) coming in .NET 4.0
Internationalisation and Unicode support from the very start - just one string type to consider, for one thing :)
Windows Presentation Framework provides a modern GUI framework, allowing for declarative design, good layout and animation support etc
Good support for interoperating with native libraries (P/Invoke is so much nicer than JNI, for example)
Exceptions are much more informative (and easier to deal with) than error codes
LINQ (in .NET 3.5) provides a lovely way of working with data in-process, as well giving various options for working with databases, web services, LDAP etc.
Delegates allow a somewhat-functional style of coding from VB and C#; this is better in C# 3.0 and VB9 due to lambda expressions.
LINQ to XML is the nicest XML library I've used
Using Silverlight as an RIA framework allows you to share a lot of code between your lightweight client and other access methods
A mostly-good versioning story, including binding redirection, runtime preference etc
One framework targeted by multiple languages:
Simpler to share components than with (say) COM
Language choice can be driven by task and team experience. This will be particularly significant as of .NET 4.0: where a functional language is more appropriate, use F#; where a dynamic language is more appropriate, use IronRuby or IronPython; interoperate easily between all languages
Frankly, I just think C# is a much cleaner language than VB or C++. (I don't know Delphi and I've heard good things about it though - and hey, you can target .NET with Delphi now anyway.)
The upshot of most of this - and the soundbite, I guess - is that .NET allows faster development of more robust applications.
To address the two specific issues you mentioned in the question:
If your customer is running Vista, they already have .NET 3.0. If they're running XP SP2 or SP3, they probably have at least .NET 2.0. Yes, you have to download a newer version of the framework if you want to use it, but I view that as a pretty small issue. I don't think it makes any sense to compare the size of your application with the size of the framework. Do you compare the size of your application with the size of the operating system, or the size of your IDE?
I don't view decompilation as nearly such a problem as most people. You really need to think about what you're afraid of:
If you're afraid of people copying your actual code, it's usually a lot easier to code from scratch if you're aware of the basic design. Bear in mind that a decompiler won't give local variable names (assuming you don't distribute your PDB) or comments. If your original source code is only as easy to understand as the decompiled version, you have bigger problems than piracy.
If you're afraid of people bypassing your licensing and pirating your code, you should bear in mind how much effort has gone into stopping people from pirating native applications - and how ineffective it's been.
A lot of the use of .NET is on the server or for internal applications - in neither of these cases is decompilation an issue.
I've written more on this topic in this article about decompilation and obfuscation.
To name a few:
Automatic memory management, garbage collection
Type safety
Bounds checking
Access to thousands of classes that you will not have to create
OK first up, No one language/platform is ever going to be universally superior.
Specialization will always provide a better use case in certain areas but general purpose languages will be applicable to more domains.
Multi-paradigm languages will suffer from complex boundary cases between paradigms e.g.
Type inference in any functional language that also allows OOP when presented with sub classes
The grammar of C++ is astonishingly complex, This has a direct effect on the abilities of its tool chain.
The complexities of co/contra variance coupled with generics in c# is very hard to understand.
Older languages will have existing code bases that work, this is both positive (experience, well tested, extensive supporting literature) but also a negative (the resulting inertia against change, multiple different ways to do things leading to confusion for new entrants).
The selection/use of both languages and platforms is, as are most things, a balancing of the pros and cons.
In the following lists Delphi has some of the same pros and cons, but differs on many too.
Potential Negatives of .Net (if they are not an issue to you they aren't negatives)
Yes, you need the runtime deployed (and installed), and it's big.
If you wanted a language with multiple inheritance you're not going to get it
The BCL collections library has some serious flaws
Not widely supported outside the MS universe (mono is great but it lags the official implementation significantly)
Potential patent/copyright encumbrance
Jitted (ignoring ngen) start up time is always going to be slower and more memory will be needed.
There are more but these are the highlights.
Potential Positives (again if they don't matter to you)
A universal GC, no reference counting that prevents certain data structures being usable, I know of no widely used Functional language without GC, I can't think of significant language of the last 10 years without at least optional GC. If you believe this is not a big deal you would appear to be in a minority.
A large BCL (some parts not so good as others but it's very broad)
Vast numbers of languages (and a surprising number of paradigms) can be used and interact with each other (I use c#, f#, C++/CLI within one wider application using each where it makes most sense but able to easily use aspects of one from another).
Full featured introspection combined with declarative programming support. A wide variety of frameworks become much simpler and easy to use in this manner.
Jitted - alterations in underlying CPU architecture can be largely transparent, sophisticated runtime optimizations not available to pre-compiled languages are possible (java is doing rather better on this currently)
memory access safety
Fusion dll loading and the GAC for system dlls
Likewise specifically for c#
Con:
Syntax based on C underpinnings
(pre 4.0) late binding solely via inheritance
More verbose than some imperative languages
poor handling of complex embedded literals (regexes/xml/multi line strings)
variable capture within closures can be confusing
nested generators are both cumbersome and perform appallingly
Pro:
Syntax based on C underpinnings
Much functional support through lambdas
Expressions allowing compile time validation of non code areas such as Linq to SQL
Strongly typed but with some Type inference to make this easier
if you really need to unsafe is there for you
interaction with existing C++ ABI code via P/Invoke is both simple and clear.
multicast event model built in.
light weight runtime code generation
The C underpinnings really is a pro and con. It is understandable by a vast number of programmers (compared to pascal based style) but has a certain amount of cruft (switch statements being a clear example).
Strong/Weak/Static/Dynamic type systems are a polarising debate but it is certainly not contentious to say that, where the type system is more constraining it should strive to not require excessive verbosity as a result, c# is certainly better than many in that regard.
For many internal Line of Business applications a vast number of the .Net platform Cons are absolutely immaterial (controlled deployment being a common and well solved problem within corporations).
As such using .Net (and this does largely mean c#, sorry VB.Net guys) is a pretty obvious choice for new development within a windows architecture.
The "simplicity" of developing complex(and simple) applications using it. A lot of basic stuff is already coded for you in the framework and you can just use it. And downloading 35mb file today is much easier than 2mb file 8-6 years ago.
There are a lot of reasons. I don't know much about RealBasic, but as far as Delphi goes:
Less widespread than .NET, smaller development community. Many of the Delphi resources on the net are ancient and outdated.
Until Delphi 2009, Delphi didn't have full unicode support.
I don't know about Delphi 2009, but 2007 didn't have very good garbage collection. It had some sort of clunky reference counting that required some intervention on behalf of the developer. .NET has a much more advanced GC that does virtually everything for you.
.NET has a larger standard library and more up-to-date 3rd party libraries.
.NET languages like C# are arguably better, and certainly easier to understand for those new to the language.
There's a lot of supposed advantages cited by .NET developers here that shouldn't be in that comparison, simply because Delphi has them as well:
Type safety
Bounds checking
Access to thousands of classes (components) that you will not have to create
There are however some things in .NET that Delphi doesn't have out-of-the box, and only some of those can be added by libraries and own code. To name a few:
Support for multiple languages working on top of the same runtime - allowing to choose the matching language for the problem (e.g. functional programming using F#)
Dynamic source code generation and compilation - this is something so alien to Delphi programmers that they probably don't even see how it could be useful [1]
Multicast events
Better multi-threading support (for example BackgroundWorker class, asynchronous delegates)
Seamless support for both 32 and 64 bit processes
Weak references
[1] If you don't know but are interested, check out the home page of Marc Clifton, especially the articles about declarative programming.
Edit: I'd like to respond to the comment by Mason Wheeler:
Re dynamic code: I know that there are solutions to have Pascal scripting embedded in the application. There is however a distinct difference between making parts of your internal object hierarchy available to the scripting engine, and having the same compiler that is used for your code available at runtime as well. There are always differences between the Delphi compiler and the compiler of the scripting engine. Anyway, what you get with .NET goes far beyond anything that is available for Delphi. And anyway, it's not the point whether one would be able to code similar infrastructure for Delphi, the point is that with .NET it's already there for you, when you need it.
Re Multicast events: Exactly, there's ways to code it, but it's not part of Delphi / the VCL out-of-the-box. That's what I was saying above.
Re weak references: You are sadly mistaken. Try to use interfaces in a non-trivial way, creating circular references on the way. Then you have to start to use typecasts and wish for weak references.
Well, the .NET Framework is shared for all .NET applications, so you have it only once on your machine and 35MB are nothing today (compare it to the size of your Vista installation). For your second .NET application you don't have to download it again.
For Windows app, .NET (using C# or whatever) gives you more direct access to the latest and greatest Windows features. It's also very well supported by Microsoft, has a huge community and lots of books written about it.
REALbasic (now Xojo) is for cross-platform apps. Using it just on Windows can sometimes be useful, but that would not be its strength (which is that it's amazingly easy to use).
I don't know much about Delphi.
From what I can see RealBASIC doesn't have much (if anything) in the way of Object Relational tools and probably wouldn't be as good a choice for n-tier, database-centric applications.