System.Threading.Thread, Universal Windows Platform, and the fragmentation of .NET Standard

This post is chiefly directed at .NET developers and others involved in the various stages of .NET deployment, in particular, anyone that’s been keeping tabs on the situation with the new cross-platform, open-source .NET Core initiative or .NET Standard, which came about as Microsoft’s response to the increased fragmentation of the .NET Platform as a result of the myriad of different deployment targets now available. If you’re not into that kind of stuff, feel free to skip this post, or read on and we’ll try to explain things sufficiently as we go through.

When a new Microsoft, with Satya Nadella at the helm, first open sourced the .NET Platform on November 12, 2014 it became clear that they fully intended to put everything they had into the initiative and that great things and big changes were coming to the .NET Framework and its languages. But what it also signaled was the inevitable beginning of a new level of fragmentation for the Framework, which had thus far – by and large – resisted any major fragmentation for the past 12 years of its existence.1 But taking a framework that was cobbled together from parts old and new, built atop of WIN32, GDI, and various Windows-specific anachronisms meant that porting the .NET Framework as-is to other platforms was nigh-impossible — and that major changes would have to be made to support this gargantuan effort.

Continue reading

  1. There are notable exceptions to this, namely the .NET Micro Framework, the .NET Compact Framework, and Mono; however, these “members” of the .NET ecosystem – one not even by Microsoft – were never considered to be first-class .NET Targets within or without Microsoft. 

Microsoft to Push Silverlight via Redesigned Website

Microsoft SilverlightSeveral months ago, Microsoft inserted themselves into the RIA framework business – years too late and against pretty scary odds – with the initial release of the Silverlight framework. Microsoft Silverlight is the online counterpart to the Microsoft .NET 3.0 Framework and a direct Adobe Flash/Flex competitor.

Microsoft isn’t new to the whole “virtual” monopoly business (where a single company holds the entire market thanks to “superior technology” and “better business sense”) – it’s just not too often that they’re on the wrong side of this particular proverbial fence.

When Silverlight was first announced and PopFly, Microsoft’s social network built to demonstrate and hopefully kickoff Silverlight, were simultaneously launched; we were quick to appreciate the technical aspects of .NET and WPF taken online, but were careful to make it clear that we didn’t think it stood much of a chance.

But things might be on the verge of a big change. Large portions Microsoft’s website are in the middle of a redesign that will feature a fully Silverlight-powered interface – doing away with HTML and everything else. We’ve had a chance to test the new interface (currently in beta), and here’s what we think:

Continue reading

Microsoft’s .NET-Powered Windows Live Writer

Believe it or not, Microsoft’s Microsoft .NET LogoWindows Live Writer is important in more ways than one. To most PC users, Windows Live Writer is simply the best tool that gets the “job” done. More importantly is how “job” is defined though, because WLW does things quite well and quite thorough.

Windows Live Writer has a huge range of options and takes advantage of almost all the features and functionality available via remote blogging/XMLRPC that make it almost pointless to even enter your blog’s administration center. You can upload images and movies, set categories and keywords, specify the slug/permalink to posts, modify the post date, set passwords on posts, send trackbacks, manually create an excerpt, and even specify whether comments are or aren’t allowed on any given post – all this without leaving your desktop client.

But what most don’t know about Windows Live Writer is more what it represents than what it does: Windows Live Writer is the first full-scale consumer product to ship out of Microsoft’s camp built on the .NET Framework.

Continue reading

Complete .NET Portability with Wine & Mono?

Mono is the open-source version of Microsoft’s .NET Framework. It implements most of the backend framework features, but unfortunately, falls flat on its pretty little face when attempting to display the user interface – which is what desktop apps are all about.

Wine on the other-hand, is a Linux port of (major parts of) Microsoft’s Win32 library – the core dependencies of the Windows development libraries, and more importantly, the win32 interface elements. With Wine, you can run many traditional C++ win32 executables on Linux, with certain limitations.

Mono’s biggest stumbling block is the GUI and .NET programs that use P/Invoke to call native non-managed win32 dlls – Mono is a pure .NET environment, and can’t handle them. But from the description above, that’s exactly what WINE excel at… So can’t we use WINE + Mono to make just about any .NET program run on Linux fresh out of the .NET compiler?

Unfortunately, the answer is no. Back when the Mono project was first starting out, the Mono development team considered using WINE to implement the System.Windows.Forms namespace of the .NET Framework (which is practically 100% native C++ unmanaged win32 code in .NET wrappers). But they made the right choice in deciding to not take the easy way and go that route, leaving the integrity of the Mono project intact and focusing on true cross-platform user interface libraries instead (the GTK# is now the UI Library of choice for cross-platform .NET applications).

Continue reading

Managed Pointers to Managed Objects (or Aliases for Objects) in C# and Visual Basic .NET

One of the biggest advantages of managed frameworks/platforms like Microsoft’s .NET Framework (and it’s Linux-counterpart, Mono), and Java is that you, as a developer, have a choice of not mucking around with pointers. To be totally honest, with Java you’re forced not to – in C#, it’s a choice you have to make.

There’s plenty of good reasons for not using (unsafe!!) pointers, but that’s not the issue here. The question is, what if you want something to “point” to another object, and synchronize it’s value automatically, without resorting to unsafe pointers? There’s actually a quite simple answer using just a single line of C# code.

Whereas in C++ you could write something like what appears below, in C# you’d have to declare it as unsafe, then jump through a hundred hoops to get it to properly point to a managed object:

Continue reading

Mono Doesn’t Get Enough Credit

Reading through the daily Techmeme headlines, there was a story that would make any Windows’ developers’ hearts stop: “Microsoft Hosts Demo of Silverlight on Linux”

Beat. Beat. Beat. Beeeeep. Beeeeep. Beeeeep. <click>. Beeeeep. <wait>. Beeeeep. <read>. Beat. <relax>. Beat. Beat.

OK, so maybe that’s a bit of an over-exaggeration, but not by much. Microsoft demoing Silverlight on Linux? What has the world come to?! But the subtitle on the PC World article cleared things up: Microsoft France invited the Mono team to demo their own version of Silverlight that runs on Linux. Now that makes more sense.

Continue reading


They invented XML for a reason… So why doesn’t anybody use it? eXtensible Markup Language is the perfect format for storing configuration files and settings for many different reasons. Most obviously, it’s very clear and straight-forward. There are no two-ways about any piece of information or data. You get what you want, when you need it.

The .NET Framework does things right here, storing per-application settings in “.config” files in the user and/or the application directory that have the settings listed in valid XML data which nest correctly and can be easily accessed via an auto-parser in the application itself. Linux now uses XML files for many of its configuration (well, not XML per-say since they don’t use a recognized top-level namespace, but the XML hierarchical structure is there alright). So why can’t Windows just cut to the chase and make the switch – only good can come of it!

The registry may be a nice “hierarchical” place to store bits and pieces of data… but the problem is that it is prone to corruption and conflict because of the way the API is designed. The registry API doesn’t enforce strict hierarchical data access for read and write, so many times things go haywire. Like Windows Explorer for example. Fellow blogger Kristan Kenney has just posted (yet another) bug in Windows Vista that ends up with Windows Explorer thinking every single folder on your hard drive is a photo album — and displaying the files as such!

Continue reading

SharpDevelop “invalid EventMemberSpecifier” Error & Solution

The Problem

SharpDevelop, for those of you that haven’t heard of it, is a very light-weight open source alternative to Visual Studio 2005. It doesn’t have all the frills and features that Microsoft’s professional IDE does, but in exchange it gives you much less bloat, faster speeds, and quite a few nifty built-in tools like SVN integration, FxCop auto-checking, code profiling, language conversion (C# <-> VB.NET <-> Boo#), and a bit more – but it has its drawbacks, too.

SharpDevelop is intended to be a 100% open source drop-in replacement for the Visual Studio IDE on Windows (there’s MonoDevelop for Linux if you like), and for the most part, it works just fine. But once in a while, an odd quirk pops up that’s rather obvious & common… yet unsolved and makes us wonder.

Continue reading

Please Microsoft, Stop Holding .NET Back!

As dedicated developers, end-users, and champions of Microsoft’s .NET Framework, we’re making a final plea to Microsoft and the .NET Framework team to save .NET and make it a real multi-platform framework. Please!

Sun could (and did) do it with Java, so why can’t Microsoft just swallow the pill already and provide real support for the .NET Framework on all operating systems? Yes, that includes Linux and Mac too. It’s ironic, because the .NET Framework has so much potential as a platform with its unique multi-language structure, nifty features, excellent libraries, (relatively) well-performing output, and darn-good innovative technologies like LINQ coming-up and XAML already here. Yet Microsoft just doesn’t realize that if they truly want .NET to succeed, they’ll have to bite the bullet and stop pretending that only officially supporting Windows won’t make users leave Linux/Mac/BSD/Whatever and buy licenses for Windows instead.

Continue reading