Delphi to .NET + C#

Question

Hi,

I've been a Delphi (D7) developer for many sometime already, I've always been wondering about the .NET + C# stuffs. What I mean are about not the "Delphi for .NET" or "Oxygene" tech/plugin, but clean .NET/C#.

How much different is it from Delphi? And some other questions...

• Is Mono/SharpDevelop (any others that I should know of?) as capable as the Non-Free Visual Studio?
• In terms of deployment, how does it work? The Assembly + Framework + Executable?
• The Framework (3.5 latest?) works something like the JVM for the Java world, correct? Does it take care of the supporting/making use of techs like Multi-Cores or Windows specific optimizations?
• C# has some similarities to Object Pascal, shouldn't be too tough to adapt, right?

Thanks.

Answer 1

Re the first point: have you tried the (free) VIsual Studio Express Edition? For a lot of things, this is perfectly capable. You just don't get as many helpers / designers, and no plug-in support (for IDE extensions).

Re the second: excluding some nasty tricks, you can't create a pure native executable from .NET; it relies heavily on the framework being available on the local machine. An assembly is just a package of IL, and can be contained (typically) in either a dll, or bootstrapped into an exe that loads the assemblies entry-point; but in this scenario the exe is just a simple loader plus a regular assembly.

Actually, the CLR is more like the JVM; the "framework" is really just the equiavalent of a BCL. The main MS framework+CLR certainly has some Windows specific optimizations, but other runtimes/frameworks (compact, micro, Silverlight, Mono) will have different optimizations.

Re multi-core - you have full threading support (for doing it yourself) - but the main automated multi-core support will (hopefully) be in .NET 4.0 with the "parallel extensions" work.

Re the last point: should be very familiar indeed. Actually, if you want to do some comparisons, "reflector" (free) can take a compiled assembly and show you the code in either C# or delphi (or a few others).

[update re questions]

IL = Intermediate Language; .NET doesn't compile to native CPU instructions, but to something in-between that becomes CPU instruction at runtime (compiled "Just In Time" (JIT) on a method-by-method basis). This means that the JIT compiler can optimize the same IL for the local machine. You can do this in advance using NGen.

CLR = Common Language Runtime; essentially the VM

BCL = Base Class Library; the set of classes shared my many apps

Re deployment: first, install the .NET framework on the client ;-p

After that - various options. At the simplest level, you can just copy the exe/etc onto the local machine and run. For example, I use "robocopy" to push code to web-servers.

For full local installs of a complex client app, msi is an option (and the full VS IDE will help you with this).

For simple clients, you can use ClickOnce - which packages the app into a signed bundle that provides self-updating etc capabilities and allows you to make statements about what security you need (full trust, etc). Express Edition allows you to author ClickOnce packages. ClickOnce can even be used on locked down clients where the user can't install apps, since the app is isolated and sand-boxed.

Finally, you can run a .NET app off a network share, but there are some security implications: the "Code Access Security" layer won't give a network share "full trust" (although there were some recent changes to this so that mapped (F: etc) shares are trusted). So you'd need to use CASPOL at each client to trust the code. ClickOnce would be easier ;-p

Answer 2

As an addition to Marc's answer, these were the minor pleasant surprises during my transition from D6 to C#:

• better OOP, no global variables ("var MainForm: TMainForm" and the like)
• everything is strongly typed (in general, you can have no pointer types)
• with Windows Forms, the "textual .dfm file" (here YourForm.Designer.cs) is actually C# code rather than a resource description in a custom language. (This changed dramatically with WPF and XAML, though.)
• custom value types ("structs") are possible (e.g. you can have a "complex" type that behaves just as an integer or a single, living on the stack)
• operator overloading

And the minor unpleasant surprises:

• no Delphi-like class references ("class of xxx", e.g. "type TControlClass: class of TControl")
• no indexed properties (you can fake that with nested classes, though)

Well, that's all I can think of right now, a few years down the road.