Merging modern software development with electrons and metal
Random header image... Refresh for more!

My .NET Notes and Books

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.

July 17, 2013   1 Comment

There’s No Substitute For The Real (.NET) Thing

Sometimes, the .NET framework’s backwards compatibility doesn’t work, and you have to install the exact version required by an assembly.

Recently, I was working on a project that used a number of components compiled for .NET 1.1 (I didn’t have the source code) — and, since I strongly prefer Visual Studio 2005 over the earlier versions, I was writing my test code in VS 2005, which installed .NET 2.0 only on the computer.

The result?  No obvious error messages from .NET (which I would’ve expected if there were version incompatibilities), but the .NET Remoting portion did not work.  The only error message was about being unable to serialize an object.

The solution?  I installed the .NET framework V1.1, and the Remoting (and serialization) problems went away.

November 20, 2010   No Comments

The Case of the Disappearing Exception

I was doing some debugging recently on an inherited Visual Basic.NET codebase. Something odd was going on – the code that reads a PLC’s input was always returning True, but I could see the input changing. The problem? The original programmer, who I’ll call “Bugs Bunny”, didn’t understand exception handling at all.

The function, part of a class that communicated with a PLC, went roughly like this:

Function bubba() As Boolean
    bubba = True
    Try
        bubba = getResultFromPlc()
    Catch ex As Exception
        logException()
    End Try
End Function

Since all Exceptions are caught and not handled any Exceptions raised in bubba()’s Try block just disappear. So all the code calling bubba() has no way of knowing if there are problem (such as the PLC isn’t powered or the serial port isn’t connected) . Instead, because the return value is initially set to True (bubba = True), if an Exception occurs, bubba() always return True.

Sometimes you do need to ignore Exceptions. For example, on a maintenance screen that repeatedly reads a PLC’s inputs, it’s good to indicate if there are any problems reading the inputs, but it’s not helpful to pop up a dialog box or exit the maintenance screen. Exceptions should be ignored occasionally as needed in the calling code, not completely swallowed up in the base library code.

Another common anti-pattern in Bug’s code is:

Sub joe()
    Try
        blah()
        blahblah()
    Catch ex As Exception
        logException()
        Throw ex
    End Try
End Sub

Sub groovy()
    Try
        joe()
    Catch ex As Exception
        logException()
        Throw ex
    End Try
End Sub

What’s the point? All that happens is the exception gets logged multiple times (adding confusion to the log file), more useless code is added (making the code harder to understand), and the program runs slower (throw, catching, and re-throwing Exceptions takes time).

Tony

June 24, 2008   2 Comments

Write Microsoft .NET code faster with Boo

even if you’re using C# or VB.NET. How? By using Boo’s interpreter to try out ideas, test usage of .NET framework functions, and interact with components (COM, .NET). Then when you’re comfortable, you can write the polished code in the language of your choice.

This is one use for mixed language programming, mentioned by me here, but where the final software might not use both languages.

In fact, any .NET interpreter such as IronPython or IronRuby could be used. And it’s a great technique for other than .NET – I’ve used it a lot with Python on Win32, and you can use it in Java with JRuby, Jython, Groovy, etc. This approach could be very useful for embedded and factory software development.

On .NET IronPython and IronRuby have advantages because they’re official Microsoft languages (and IP has a book coming out – IronPython In Action) and the languages are already in wide use (Win32, *nix, Java). I’m using Boo because it comes with the open source SharpDevelop IDE, and right now it integrates better with .NET (IP does not support attributes well, and it’s not easy to make an IP assembly callable by other .NET languages, etc).

Short example – interactively using DirectoryInfo in Boo (text I typed in bold):

>>> di = DirectoryInfo(“C:\\Download”)
C:\Download
>>> files = di.GetFiles()
(AdbeRdr80_en_US.exe, AdbeRdr80_en_US_Nosso_error.log, Firefox Setup 2.0.0.1.exe, SharpDevelop_2.2.1.2648_Setup.msi, TortoiseSVN-1.4.3.8645-win32-svn-1.4.3.msi)
>>> files = di.GetFiles(‘t*’)
(TortoiseSVN-1.4.3.8645-win32-svn-1.4.3.msi)

Interactively calling a COM object in Boo:

>>> ieType = System.Type.GetTypeFromProgID(‘InternetExplorer.Application’)
System.__ComObject
>>> ie = System.Activator.CreateInstance(ieType)
System.__ComObject
>>> ie.Visible
false
>>> ie.Visible = true
true
>>> ie.Visible
true

So far I haven’t had to use InvokeMember to call COM functions. At least for C# and VB.NET (and probably Boo) it appears you need to use it if you are using late binding. BTW, it is possible to use late binding with COM events, but it is significant extra work.

Tony

September 26, 2007   No Comments