ASP.NET

I read an article by Rick Strahl called “ASP.NET Gets No Respect”. Rick stated that ASP.NET offers great flexibility. He said it can be done easily. And although the framework is big, the model is clean. Usually a single machine can handle the load. You don’t need to do load balancing. People call ASP.NET both slow and insecure.

The competing technologies for ASP.NET are PHP, Python running on Apache, and LAMP. A downside to ASP.NET is that it is not free. You have to pay for Microsoft Windows. Most big sites do not use it. However some popular sites like MySpace, Dell, and CareerBuilder do.

Rick did say that you need to make a large up front investment in learning to do ASP.NET well. There was a lot of excitement when ASP.NET first came out. However it has been stagnating ever since .NET 2.0. Other areas in .NET such as WCF, WPF, and LINQ are hot now. But ASP.NET is just not a hip technology. You normally do not see startups using it. Microsoft is, however, very popular in the enterprise.

There were a lot of comments to Rick’s article. Some commented that Microsoft does provide support. But PHP is much simpler. A few people argued that they had to reboot their servers when they ran ASP.NET applications. Others complained that Visual Studio is just plain slow. There were a whole lot of other complaints, mostly about Microsoft.

Some web developers on my team use classic ASP for the web sites they run on the side. They seem pretty content. However I do see these guys having to reboot their servers sometimes when things go awry. They also get their customers to pay for the Windows Server operating system and hardware. So perhaps this is not a fair comparison. I can say that I have neither any experience with classic ASP or ASP.NET. I am really not a web developer. And for work I suspect I may have to go the Java route based on the client’s decision. I still wanted to talk about ASP.NET a little bit today though.

Unmanaged Into Managed

The other day I read the latest blog post on the Coding The Wheel blog. It was entitled “How to Inject a Managed .Net Assembly (DLL) into another process”. The author is James Devlin, who wrote a series of articles on how to write a poker bot that makes money. I will not go into the details of how you perform this injection. See James’ post for the full details. However I though his outlook on what managed code really means is interesting.

James comes out and says there is really no difference between managed and unmanaged processes. All applications are always unmanaged. Managed just means you have access to .NET, and there is a Just In Time compiler. James’ idea is that an unmanaged application can load the .NET runtime. So the call stack is that an unmanaged DLL loads the .NET runtime, and the runtime invokes your managed assembly.

James did state that loading the .NET runtime was not a trivial task. And somebody who commented on the blog post added that you could have problems if you tried to inject a .NET version 3.5 DLL into a .NET version 2.0 host.

I spent some time trying to get a mental image of what is exactly happening here. The main application James is talking about is truly unmanaged. However it invokes the .NET runtime. So the part in the middle that is injected is actually managed. Perhaps this is a way of an application running both managed and unmanaged code at the same time.

While it is true the application that starts the injection is indeed unmanaged, the code that gets injected is managed. Also I think it is obvious that in the end all code gets executed by the CPU. However this does not necessarily mean that all code is managed. Maybe this is just a semantics issue. However the code that James injects is an assembly that must conform to the .NET framework. In the end it executes as native code. But it is still managed.

This may all be much ado about nothing. However James is one of the first guys that comes out and says that there is no managed code, only native code. Maybe this was the shock value needed to attract readers to the blog entry. That worked in my case.

LINQ: Good or Bad

Eric White wrote a blog entry asking whether developers are using Language Integrated Query (LINQ). I have to confess that I had heard about LINQ. But I was definitely not using it either on the job or in my side projects. So I thought I would delve a little deeper, and summarize some of the points brought up by Eric and those that commented on his post.

To start with, LINQ is an extension to the .NET framework. It extends the C# and VB languages. LINQ comes with Visual Studio 2008. It allows the developer to express query behavior efficiently. Essentially it makes SQL a part of the programming language. It addresses the database model in the context of Object Oriented Programming.

Now let's review some of the bad thing about LINQ. Not a lot of people understand it. Once again I will confess that I am no LINQ expert myself. Although I am now trying to learn more about at a high level. I heard that it is difficult to debug LINQ statements. And finally LINQ has performance issues when returning a large list of objects.

For every bad thing about LINQ, there is a good side too. Programs written using LINQ tend to have fewer bugs. It works well with C#. And for those who have delved into it, they say it provides a good return on investment. In other words you will benefit greatly if you put a little work into learning LINQ.

It takes about a week to get the hang of LINQ basics. And it will take closer to a month to get to a deeper knowledge of the technology. When LINQ is coded on top of stored procedures, it makes for simpler code. Finally I have been guided to use IEnumerable extension methods but not the pseudo SQL syntax. Well I do not know enough about LINQ to qualify the last statement fully. But I may just dive in and try to my bearings so I can at least evaluate the technologies.

Microsoft Priorities

Microsoft CEO Steve Ballmer recently came out with a memo to all Microsoft employees reviewing the company priorities for the next year. This comes at a critical time for Microsoft since Bill Gates has retired. Ballmer outlined a 3 pronged focus on Windows Vista, WPF, and Silverlight. I thought I would discuss each of these as they relate to .NET development.

Windows Vista is the latest version of the Windows operating system. It was previously known as Longhorn during the development days. The O/S was released on January 30, 2007. This was a lengthy 5 years after the release of Windows XP. There has been a very cool reception to this version of the O/S. Users do not like the high level of system requirements for it. There are also a number of compatibility issues with legacy hardware and software. Early adopters complain of slow file operations. PC World called the O/S a big disappointment. And InfoWorld stated Vista was a flop. Microsoft has a lot of damage control to do with this version of the O/S.

Windows Presentation Foundation (WPF) is a .NET graphics subsystem. It was formerly known as Avalon during development. WPF version 3.0 comes standard with Windows Vista. The subsystem help aims to separate the user interface and business logic of applications. It introduces the XAML language. Microsoft is marketing WPF as a unified framework. Applications can use it in a desktop or browser configuration. The API for WPF is exposed only via managed code. But internally, its composition engine (named the Media Integration Layer) is written in native code.

Silverlight is a browser plugin from Microsoft. It competes with popular products such as Flash from Adobe. It supports animation, graphics, and audio-visual effects. Silverlight was previously named WPF/E (E stands for everywhere). It is a web based subset of WPF. As such it is designed to work with XAML. Initially Silverlight was criticized because it would only run under Windows. Version 2 of Silverlight comes with a .NET framework version that can run .NET code. Personally I get annoyed every time a web site refuses to load unless I install Silverlight. But that is just me.

There is a lot going on in the Microsoft development world. As you can see, a lot of it revolves around the .NET environment. I look forward to monitoring Microsoft’s progress in each of the key areas identified by its CEO this year.

Bloatware

At work we support a suite of applications. We bundle two of the main applications into one install program. Historically this install program has been about 17 Megabytes in size. There are a lot of business rules implemented by these applications. So some of our DLLs are pretty large even in release mode. But all of this bloat is not due to our custom code. We ship the install of the Microsoft Data Access Controls (MDAC) with each of our installs. That alone adds over 5 Meg to the install size. So far the customer has lived with this software install size. I know they must be having some pain because they push the install out to a lot of workstations.

This year we are moving to a new version of Visual Studio and the Oracle client. The move alone should not require a larger install program size. However we gained a Visual Basic Dot Net developer on out team. He has been struggling with learning the Visual C++/MFC programming that is required by our applications. It is also a chore to learn the business rules of the software. So when given the opportunity, he wrote a new piece of the software for our system in Visual Basic dot NET. I don't blame the guy for this. He was finally happy once he got back to doing what he knows best.

We gave the new developer the task of upgrading the install package for our software. Having added a Visual Basic dot NET component, he needed to ensure the right version of the dot NET framework was installed on the target platform. So he added the dot NET framework to our install program. All of a sudden, the 17 Meg install program has blown up to a 44 Meg monster. We have only pushed the new install out to our internal test team. But I expect there to be an outcry once the user community gets wind of this.

I know in this day and age, memory and disk space and bandwidth are plentiful. However users still expect installs to happen quickly. And they do not want complicated install packages. User has never liked install programs that are not fully stable. We might be heading into darker waters by ramping up our install to include the dot NET framework. The jury is still out on this. The real heart breaker is that we really did not have a solid need to do this. It was just due to one developer that was having trouble with our current software language and platform. I guess this is just life.

Stuck on MFC

I had just installed Visual Studio 2005 on my workstation. And I needed to do some rapid application development. There was no time to come up to speed. So I fell back on the framework that I was most familiar with. That is the Microsoft Foundation Classes (MFC). Almost all of my Windows application programming has been done with MFC. It proved to be beneficial when every second counted towards completing an application.

But this was not the point of installing Visual Studio 2005. I heard somebody say that, even if you have experience with Dot NET version 1.0, you are obsolete. And I have not even reached that point yet. I am wondering if it is even worth getting into the Dot NET framework at all. I have a rapid application development tool set, albeit an old one. The new is that there is a new version of MFC out for Visual Studio 2008.

There may still be some application for which Dot NET is the best tool to use. So it would be best if I at least learned the basics to be able to tell which technology to use. It seems like this skill would help on interviews as well. Everybody is either into or going towards Dot NET. I met a developer that needed some expertise in my client's particular domain. He was impressed with my C# book library. I told him I just played around with it and found it similar to Visual Basic. He told me that F# was more hard core, and was something I should look into. Too bad I know little about it.

Time to hit the books and documentation. I have the IDE. Now its time to get to work. Good luck to me. If in the end I discover that this Dot NET business is all hype, at least I will have done the research myself and formed an opinion. I hope that Microsoft has not come out with a new methodology by then.

Visual Studio 2005 Installation

I got a trial copy of Visual Studio 2005 Team Suite from Microsoft. And today I finally got around to installing the darn thing. The trial version remains active for 180 days. Should be enough time to get my bearings.

One confusing thing was that my trial copy got shipped with 4 DVDs. It was not intuitively obvious which of these 4 DVDs I should install. The SQL Server 2005 DVD was obviously not the right one. But there was a Visual Studio 2005 Foundation Server DVD. There was also a Visual Studio 2005 Team Edition for Database Professionals DVD. In the end I chose the DVD entitled Visual Studio 2005 and hoped for the best. I guess Microsoft assumes you know what to install.

I chose to do a full installation. This amounted to 4G worth of disk space. Should not be a problem as I have a large hard drive. But what is all this stuff? Once I was done, I found that the version I had chosen to install was officially called "Visual Studio 2005 Team Suite". All I really care about is Visual C++ 2005. So I should be covered. In fact, the first time I fired up Visual Studio, it asked me to choose a setting. Since Visual C++ was one of the default choices, I felt confident I was going down the right path.

It was funny to see an advertisement from Microsoft during the install saying that I could "write less code" if I chose Visual Studio. I understand where they are coming from. But I like writing a lot of code. Installation took a while. So I browsed the Microsoft site to see how much this thing would cost if I wanted to buy it. Apparently they are not selling Visual Studio 2005 any more. But they do list the prices for Visual Studio 2008. The full version of professional costs a whopping $799. However standard goes for $299 for a full version. Still expensive.

Welcome to Microsoft

Currently I am a legacy Microsoft developer. That is, I use old Microsoft products to write code. I do this both at work and at home. Have not found the need or drive to buy anything more than Microsoft C++ version 6.0.

Recently I was doing a job search. The legacy skills came in handy for hard to fill positions. It seems that some jobs can't or won't be done by new college graduates. That is good for me. But the writing is on the wall. Even these legacy shops want to move to the world of dot NET.

So I figure it is finally time to get busy with dot NET. You know they say you should not trust a Microsoft product until it reaches version 3 or more. Where are we with the dot net framework? Version 3.0? Version 3.5? Sound like the time is right.