.NET: what lies ahead?

Let's return briefly to 2002--a year both celebrated for its numerologic significance to middle-aged BMW owners and darkened by its Billboard #1 hit.

Largely outlasting the former and certainly more useful than the latter was the first version of .NET, developed by Microsoft as a replacement for Java (over which they had settled a lawsuit with Sun Microsystems).

You'll remember that Java brought a new level of portability to the C language family, since it ran in a virtual machine--an aspect that made it useful for executing code from a browser.

At the time, Microsoft's primary languages for mainstream developers wanting to write Windows apps consisted of Visual Basic and Visual C++.You'll recall that the original language for writing Windows apps was good old C.

Why does that matter? Because C and C++ were both compiled languages. VB was not, but we'll get back to that in a minute.

The past

Compilers have been around since either 1952 or 1957, depending on who you want to get the credit and how you define a "compiler." In any case, all compilers convert high-level language to assembly language, because writing anything in assembly is like building a car by first inventing steel. I'm old enough to remember when the first PC word processor written in C was sneered at by developers because it would be slow compared to ones written in asm. 

LOL

Later it was popular to put _asm in your C programs and drop down into assembly to optimize a loop or sort or some other performance-sucking bit of code. We didn't trust the compiler to write optimized code, and the hardware was so feeble we really had to worry about stuff like that.

For giggles I downloaded the original source code for MS-DOS 2.0 and it's fun to read but would you really want to still be writing this sort of thing?

Here's the thing: compilers produce asm, so you can read and write memory (remember BASIC's PEEK and POKE?) and wreak havoc. Back in the days of C you had to manage your memory exactly and carefully or chaos would result (crashes, leaks, etc). 

Interpreted languages like UCSD Pascal or--more relevant to this discussion--Visual Basic used an abstraction layer between the assembly code the computer would execute and the source code. This was and is the VB runtime which is simply a dynamic link library that's invoked at runtime (and is still shipping on Windows 10). With the VB runtime, the responsibility for low-level management moved from the application to a library created by Microsoft's developers who--we hope--are thorough and careful and will do the right thing so our VB6 app won't kill Microsoft Word. Or something more life-critical. VB was great for RAD or 4GL style application development and lots of people who couldn't or didn't want to fool around with low-level OS details got interested in coding and wrote apps. 

Many of which are still around today.

What really set VB apart from C, though, was that instead of writing this (from Petzold's Programming Windows):

you didn't have to write anything. Just tell VB you wanted a new form and BOOM! all that crap was hidden away in the runtime. You could drag and drop menus and controls and it was heaven on earth. "Real" programmers coughed politely and changed the subject when they met someone who wrote VB code, but it caught on because it was fast, easy, and a lot more bulletproof than writing directly to the Windows API in C. Sure, you couldn't write a device driver, an OS, or a linker in VB but how many people did that anyway? 

.NET present

Jump ahead to to 2002 and we get .NET 1.0. By that time Windows was far more successful than probably anyone ever predicted in the early 80s when it first showed up, and there were different versions not only of Windows but of all the associated bits and pieces it needed. The result was DLL hell and various flavors of Windows that developers had to choose from to create apps. The API had grown like the clover in my lawn and it was all a lot more complicated. The Visual C++ (later Visual Studio) team had thrown a bunch of help at the problem like MFC and ATL, but more was needed and additional market pressures were at work. 

Like VB, .NET moved the responsibility to manage low-level OS functions out of the hands of the developer. Instead of Visual Studio compiling your source code to asm, it built intermediate language (CIL) and the OS would compile it later into something that made sense on whatever supported platform the app was running on.You no longer used malloc() or worried about leaks. You just created objects and let the runtime manage the heap and garbage collection. It was managed code. And it brought a level of portability to Windows that hadn't existed before. 

.NET today provides a huge set of Windows services as well as a significant degree of cross-platform portability. The center of .NET is the common language infrastructure (CLI) which is largely language and processor independent. This means you can write .NET code in C#, F#, VB.NET, and dozens more languages. And instead of distributing executable code as your application, .NET assemblies are just the intermediate language, which is either JIT (just-in-time) compiled on a target platform or compiled in advance and ready for execution. Basically any platform with a supported CLR (common language runtime) can run a .NET app.

Which brings us to...

.NET future

In 2016 Microsoft released the first version of .NET Core, a cross-platform, open-source version of .NET. Apps written to .NET Core will run on Windows, Linux, and MacOS. Because it's a cross-platform implementation, it doesn't support Windows-specific designs like Windows Forms or Windows Presetentation Framework (WPF), or Windows-specific functionality like the Registry. A version of ASP.NET Core is also open-source and provides a cross-platform web application framework, but doesn't support Webforms. 

Mobilize and .NET

Mobilize's roots are based on building tools to help people move TO .NET and nothing about that has or will change in the near future. Our VBUC tool is the world's most popular and successful technology to migrate from VB6 to C# or VB.NET. WebMAPtakes it a step further to move C#/Winforms desktop apps to well-formed web applications, using ASP.NET MVC at its core. 

Currently our implementation of ASP.NET MVC is more like WebAPI than classic ASP.NET (for example, we use JSON messaging between the client and server). A quick look at ASP.NET Core compared to what we do with WebMAP shows a lot of alignment (many of the unsupported ASP.NET stuff we don't use anyway, like WebForms). 

Our product roadmap for WebMAP includes supporting ASP.NET Core in the not-too-distant future. We strongly believe the technology world is finally becoming more diverse in terms of platform (something expected/promised/hyped for years now) and applications need to be able to run anywhere. While our roots are in Microsoft, we are largely platform agnostic (as evidenced by our PowerBuilder to Java tooling) and as such are pretty amped by .NET Core and ASP.NET Core. 

I personally go back a long time with Microsoft's language efforts, and I'm more excited about .NET Core than anything I've ever seen. I hope you are too.