An Update About Mono

I’m not one to get stuck on a particular form of a technologyit’s best to use the solution that works, rather than make a favored solution try to fit. Many .NET developers miss opportunities to move their solutions to other platforms or use them in places that normally don’t work well with the .NET Framework by leaving out Mono, the .NET Framework alternative. Most people associate Mono with the Macintosh or Linux, but there is also a Windows form of Mono. When Windows Server 2008 Server Core came out without the .NET Framework, I immediately wrote an article about it entitled, “Mixing Server Core with .NET Applications.” In fact, I’ve promoted Mono to frustrated administrators in my book, “Administering Windows Server 2008 Server Core.” Before Microsoft finally came out with a .NET Framework solution, you could use Mono to do things like run ASP.NET applications on Windows Server 2008 Server Core and my book told you how to do it in Chapter 24.

So, I was more than a little disturbed when I heard that the Mono crew had been laid off by Novell. Fortunately, I discovered later that the layoffs are just a prelude to having Mono supported by a new company named Xamarin. To read more about this company, check out Miguel de Icaza’s blog entry, “Announcing Xamarin.” Not only will the new company continue supporting the open source versions of both Mono and Moonlight (the Silverlight alternative), but it’ll create new commercial products for both Android and iOS. In short, this development is actually good because the new company will focus on this incredibly useful technology.

My main concern for the new company is that they won’t have the funding to do everything they envision doing, but that remains to be seen. Reading Mary Jo Foley’s article gives me hope that they’ll succeed. What are your thoughts about Mono? Is it a technology that you’ve used or at least are willing to try? Let me know at John@JohnMuellerBooks.com.

 

Working with Low Level Code

Working with low level code is becoming less necessary as Microsoft continues to improve the .NET Framework, but you sometimes still need to resort to direct Win32 API access using P/Invoke.  My book, “.NET Framework Solutions: In Search of the Lost Win32 API,” is a great place to learn about P/Invoke and the significant number of ways you can use it to access Windows features that Microsoft hasn’t made available in the .NET Framework yet.  For example, you’ll find a thorough discussion of the Windows messaging system in Chapter 4.  However, the discussion is a bit lengthy because there is so much you can do with the Windows messaging system.

One of the questions I get asked quite often is whether there is a quick start sort of guide I can recommend for working with the Windows messaging system.  With that in mind, I wrote a series of four DevSource articles some time ago.  Here’s the complete article list:


These four articles provide quite a bit of information about Windows messages that you might not know from a .NET perspective.  Using these techniques can save you considerable time, especially when you need to interact with other applications.  In fact, the final article reveals secrets you can use to interact with applications when you don’t have the source code; a significant problem for most developers.  So, how do you use P/Invoke?  Have you had to resort to P/Invoke to work with Windows 7 features that haven’t been added to the .NET Framework yet?  Let me know at John@JohnMuellerBooks.com.