The Developers Dilemma usually takes two forms:
- If Only I could X
- Or, How Do I X
Usually followed by a flurry of Google Searches and, depending on the platform/language you are programming in, either success or failure.
Often though, if the solution requires downloading something or setting up something new on your computer, the question usually follows:
Why isn’t this easier?
In a perfect world, these questions would be answered by, “Just call this function” or “Just use this class”. Thus, the functionality would be built-in and all you have to do is use it.
That’s the goal anyway…
Whether or not, Microsoft fully hit the mark with this in .NET, they certainly took a very good swing at it. There are a lot of built in capabilities in .Net, all exposed via API. Thus, all you have to do is know what to call and how to use it.
Luckily, while releasing the functionality, they also released detailed documentation to assist with usage. That doesn’t mean it’s absolutely 100% complete, just that it’s usually pretty good and answers a lot of questions about implementation. It’s good to know that it’s a priority for them and that there’s someone paid to create and review documentation for things like this.
One additional difference with built-in functionality is when it’s time to deploy your application, you don’t have to worry about deploying supporting applications and/or libraries. They are already there.
Windows Services are programs that run in the background on a windows machine. They perform a variety of functions and once in a while, it would be very useful for you to write one. They used to be an exercise in Black Magic followed by frustration. Nowadays (in .NET) they are pretty much implemented with a couple of API calls and a Visual Studio template that you use to create them.
Exposing and Consuming Web Services also used to take a lot of patience. Remoting/RPC (the non-web web services) was also a PITA to implement. Now with WCF, you make a couple of API calls, and use a couple of configuration files, largely maintained by Visual Studio for you, and most the the headache has been abstracted from you.
Creating an Installer used to involve third party products to get it right, and sometimes didn’t work on certain target operating system versions. This as well is built in with .NET and the process of creating them is another Visual Studio Wizard.
Windowed Applications have been easy since the first days of VB, however they are much more robust and also built into the framework. Now accessible from third generation programming languages like C#.
Messaging/Queuing for applications that process a large number of requests is also built into the framework. If you are looking for basic functionality, no need to install SQL Server or Service Broker.
Web Application functionality is built into the framework, so even though you can’t serve up an application without IIS or the Standalone ASP.NET Development Server, 90% of the components you actually use in a web application are actually a part of the Base Framework. This includes for example, needing to HTMLEncode or URLEncode something in a non-web application.
Data Handling/ORM basically is the ability to make connecting to your database a whole lot easier and with a whole lot less code. This used to be a specialized, experimental idea that was not formally accepted in the development world. It’s included now.
A Workflow Server can be a PITA to create, let alone maintain. This functionality is one of the more impressive components that… you guessed it is included in .NET
Wrapping it up
Built-in functionality wins over downloaded extra functionality hands down. Knowing this, MS has gone out of their way to provide more and more INSIDE the actual .NET Framework itself. It’s Developer friendly by exposing API Calls and will usually save you time and/or money if you get to know the components in .Net.
Don’t make the mistake and re-write any of these items yourself, make sure to first see if it’s included.