I’ve done a fair amount of VB.NET and C# .NET development. So here are some notes about .NET development techniques along with comments about the .NET books I own.
Languages
C# is deservedly the most popular .NET languages. Although some tasks such as COM interoperability are easier in VB.NET, overall I strongly prefer C#. C# has a more coherent syntax and better support for cutting edge programming techniques such as functional programming.
It’s worth considering the other .NET languages, especially in combination with C#. However, you also have to consider whether the advantages (such as clearer code and quicker development) out way the disadvantages (such as most programmers not knowing the language). For example, I’m very tempted to F# at work, but won’t, because it’s not very likely anyone else who might have to maintain my code will know F#.
Microsoft is now putting more emphasis on C++, is pushing functional programming with F# and new C# features, and has basically dropped its support of dynamic languages such as IronPython and IronRuby. However, these projects are still alive, and can make a lot of sense: for example, adding scripting to easily customize your base software for different customer requirements.
Beginning C#
I learned C# basics using Programming C# 4th Edition, 2005, by Jesse Liberty. I’d say it’s a good book; reviews for later versions are mixed. However, depending on where you’re starting from, there are probably better books.
Advanced C#
C# In Depth by Jon Skeet is a superb advanced book on C#. I have the second edition, and am very impressed with its coverage of C#’s evolution, and its explanations of how and why to use these new features.
This book illustrates one of the biggest advantages of mainstream software development: excellent advanced books. There are no PLC programming books comparable to C# In Depth.
.NET Development
I bought Juval Lowy’s Programming .NET Components, Second Edition, many years ago for half price at Fry’s. It sat around until I needed to handle asynchronous programming, send .NET events, use Remoting, and handle some concurrency. The book is a bit dated, but recently I’ve been referring to it constantly, and appreciate the well written explanations and the author’s tips based on his experience.
Programming .NET Components has chapters on component-oriented programming essentials, interface-based programming, lifecycle management, versioning, events, asynchronous calls, multithreading and concurrency, serialization, remoting, context and interception, and security. So it covers a lot of useful areas, but its age shows: for example, there’s no coverage of WCF (Windows Communication Framework) or newer approaches to concurrency.
Microsoft classifies Remoting as a legacy technology: it won’t disappear (heck, COM/DCOM is still around), but won’t be actively developed. I looked at using WCF, but decided its advantages didn’t matter to me, and that it was considerably more complex than Remoting.
I’ve looked into some of the newer .NET technologies but haven’t had a reason to use them yet, including:
The Task Parallel Library (TPL) – Microsoft’s preferred way of handling concurrency in .NET 4.0 and higher.
The Concurrency and Coordination Runtime (CCR) – originally shipped with the Microsoft Robotic Studio, but can be used for non-robotic applications.
Reactive Extensions (Rx) – intended to simplify asynchronous and event driven programs. It uses cool advanced programming techniques.
My current applications don’t benefit from massive amounts of parallelism, so right now the TPL and CCR don’t offer any major benefits. I do have some event driven programs, which I suspect could really benefit if rewritten using Reactive Extensions.
GUIs and Programming
Most developers use GUI designers to create the user interface; Visual Studio has a good designer. Using a designer is easy, initially requires less code, provides instant feedback on the GUI’s look, and provides pixel level control. However, most designer-created GUIs don’t scale well, don’t handle modifying the user interface at run time, and require a lot of work every time you want to change something.
Another approach is to create the GUI in code. This was pretty tough in the old days of straight Windows or MFC — there’s a good reason VB became so popular. However, when I did a project using Python and tkinter, I didn’t have a choice, since tkinter doesn’t have a designer.
Instead, you use layout managers to tell the GUI how to automatically place the controls (e.g. grid, vertical pack, horizontal pack). Java has similar methods. Initially, WinForms did not, but later versions added layout managers, although I doubt they’ve been used a lot.
The advantages are that you can make the GUI much more flexible: scalable, adding controls at run time or based on a table or configuration file, and such. On the flip side, there’s more work up front, you don’t have the same level of layout control, and you do spend a lot of time running the GUI just to tweak the layout.
A third approach is to use a declarative GUI, where you can define the GUI’s elements by declaring them in a configuration file. (Side note: Windows Installer uses a similar declarative approach.) WPF (Windows Presentation Foundation) supports declarative GUIs using XAML files. You can also create WPF GUI’s using a designer (including Microsoft’s stand alone designer, Expression) or using code.
As my readers from Kickdrive.de have pointed out, the well regarded Qt GUI library now supports declarative GUIs. However, Qt is not well supported in the .NET world although there are bindings such as Qyoto and Qt4Dotnet (which hasn’t been updated in a while).
I’m currently still using WinForms, but that’s because of the project’s requirements.
DSLs and Meta-Programming
DSLs are domain specific languages; in other words, special purpose programming languages made for a specific use, not general usage. The advantage is that DSLs can be tailored to match the needs of the domain users, not those of programmers. Then there are DSLs for developers, such as easyb, a story verification framework using a DSL written in Groovy. Take a look at easyb in action — it’s very different from C# or Java.
There’s at least one book on creating DSLs in .NET: DSLs in Boo by Ayende Rahien. I don’t own it yet, but I’ll probably add a used copy to my next Amazon order.
Metaprogramming is programs that write or manipulate programs. Metaprogramming is impossible in ladder logic and many other languages; it’s easiest in dynamic languages such as IronPython. At its best, metaprogramming can add a lot of flexibility and eliminate huge swaths of boilerplate code. At its worst, metaprogramming can make spaghetti code look good, so it should be used with care.
I wrote a settings module with metaprogramming; to add a settings variable, I just added its specification (name, type, etc) to a table, and the Python code could automatically load and save the variable, add it to the settings dialog, and add it to the settings object — pretty cool, and a lot less work than doing all that by hand.
Functional Programming
Functional programming has attracted a lot of attention recently, partly because it can ease the pain of parallel programming. I’m not a total convert, but I do like to use some functional techniques, and have been learning more. I have three books on functional programming using .NET:
Functional Programming in C# by Oliver Sturm– a good book with clear explanations of how to do various functional techniques in C#. If you’re looking for an introduction to functional programming, look elsewhere. But if you want to use functional programming in C#, get it.
Programming F# by Chris Smith. I have the first edition, and I’ve done a quick first read — it’s a good book, and F# is an intriguing and very powerful language.
Real World Functional Programming With Examples in F# and C# by Tomas Petricek with Jon Skeet. I haven’t read it yet, but it looks very interesting: at a glance, it’s chock full of practical examples.
F# is pretty far above ladder logic. I wouldn’t recommend it as the control language for a high speed packaging line, but it can easily handle data manipulation tasks that would be impossible in ladder logic.
Testing and Development
As I’ve mentioned before, The Art of Unit Testing by Roy Osherove is an excellent book, well written and filled with practical advice. I recently bought Test Driven Development in .NET by James Newkirk and Alexei Vorontsov; the review are good but I haven’t read it yet. Applying unit testing is a bit harder with automation: I can see how I could apply it to communications code, but not to motion code.
IronPython In Action by Michael Ford and Christian Muirhead is worth considering, even if you don’t plan on using IronPython as your main language, because it can show you some different approaches with its chapters on unit testing, metaprogramming, WPF, and scripting.
Communities
One big difference between mainstream software development (such as Java, .NET, and C/C++) and automation development is that on automation side, development is vendor driven, while the mainstream development community has drive a lot of advances such agile development, lean development, unit testing, Test Driven Development (TDD), Behavior Driven Development (BDD), continuous integration, distributed version control (git, mercurial), refactoring, design patterns, and DSLs.