3

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.

Toon Krijthe
  • 52,876
  • 38
  • 145
  • 202
Atlas
  • 1,353
  • 5
  • 19
  • 32

3 Answers3

4

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

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Thanks for the info. About the deployment, I don't quite understand... Could you give me a example, for say "Deploy a Application (Database connected) to a client machine", normally what needs to be done? Sorry to ask, but what are "IL" + "BCL" + "CLR"? – Atlas Oct 26 '08 at 08:35
3

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.

Alan
  • 6,501
  • 1
  • 28
  • 24
  • 1
    I would add "Interface" to the pleasant suprise list. Delphis interfaces are terrible to work with as they require reference couting. In C# they are smooth as silk. – Martin Liesén Oct 28 '08 at 13:28
  • 1
    Delphi interface can work without refcounting. Of course because no GC is used the interface implementor lifetime is up to the code. Anyway I would not call lack of pointers or global variables/function a pleasant surprise - it is more like a nightmare –  May 25 '11 at 18:19
  • 1. A static member is more or less a global variable. Just a diverse syntax, but could lead into the same OOP architecture problem. 2. Delphi has strong typing for pointers too - abuse of pointer is bad, we all agree, but they are some times the faster and the better. 3. This is a personal opinion, and depends on your habit - who edits the .dfm content manualy? 4+5. With modern version of delphi, you can have such custom value types with operator overloading. – Arnaud Bouchez May 26 '11 at 06:47
0

Delphi was written by the same person who wrote C#, so the overall structure of the language would not be the toughest transition. You also have to keep in mind that C# is C-like while Delphi is Pascal. I tried looking Delphi after using C# it was a very tough transition. First no garbage collection, second like @Alan stated the global variables are tough. You do have inheritance with C# but you do not need to declare Form a variable of TForm etc. Thirdly Deployment was a huge pain. With .Net and GAC you really just build your solution and your off. Fourthly, that is a much greater worry about continued support with Delphi. It is now on its third company. I would think going the oppose way Delphi to C# would be much easier.

Joe Tyman
  • 1,417
  • 5
  • 28
  • 57
  • Delphi produces standalone executables that used "xcopy deployment" far earlier than .NET. Most software around works without a GC. Like any hybrid OO languages (like C++), using global variables is up to you. The global TForm variable created by the form wizard is just a convenience. You can delete it as long as you know how to free the form when it is destroyed. At least you don't need to declare dummy classes just to store global data. –  May 25 '11 at 18:25
  • I can add dll after dll to my software and not have to worry about it with .Net. While for a simple exe this maybe worthless it is very for valuable a complex piece of software that I have a lot of libraries. Without GC either coded by yourself or by the code itself would created memory leaks, with values bound to form this is less of an issue. While C++ is a workhorse Java and C# exist for a reason, global is not a smart idea, and is unnecessary in OOP. – Joe Tyman May 25 '11 at 19:21
  • *You do have inheritance with C# but you do not need to declare Form a variable of TForm etc.* The lack of the distinction convention of Delphi gives me headaches with reading Visual Basic or C# I got on searches... – Fabricio Araujo May 25 '11 at 19:27
  • With Delphi there is far less need to add "DLL after DLL" to a software. And even if you do is just "xcopy" to a folder, unless you prefer to be **professional** and use an installer. Java and C# exist for reason, the ability to hire cheap programmers who can't avoid memory leaks and can fire in their feet with pointers. Globals are necessary in OOP too - why developers implement fake classes to store global data and implement global functions? –  May 26 '11 at 08:07
  • Yes the added cost of an installer makes sense for every small business who happen to have the need for custom software. Delphi is not a bad language like you seem to think C# is. It is just a product of the 90's and child of Pascal. Those things seem to hurt in 2011. – Joe Tyman May 26 '11 at 16:44
  • InnoSetup is a zero cost installer, and I repeat, that's just the *professional touch*, you can deploy without if you like and you do not need to initializa conf files, the registry and the like. I do not think C# is a bad language, but Delphi is not either as many here think, writing not true statemets about it. C is a a product of the '60s, and C++ of the '80s. Do they seem to hurt today? Why Pascal should hurt in 2011? Just because it doesn't use a C-like syntax? But its syntax is as much as powerful as C++ (but multiple inheritance), so what the problem? Just you are not used to it? –  May 27 '11 at 14:53
  • Pascal was created to be a teaching language, while C was designed for Unix and Unix for C. Pascal evolved largely because an article called "Why Pascal is not my favorite language". If you want manipulate bits of course you are going to use C. If you are going to make a serious piece of software (like an OS) you are going to use C++. Delphi was great for RAD software. It is much better than VB 6.0 and can still go toe to toe with VB.NET. Personally I don't like have English words in my code. Delphi and VB have tons. Begin, End, then, etc... C-like syntax is much better for that. – Joe Tyman May 27 '11 at 15:15