Can someone explain .NET Framework to me?

Not the technical aspects, but more in terms of why it was needed in the first place, what it’s used for, what it’s good for, who should become familiar with it, and where do you start to bring yourself up to speed with it.

In the most basic analysis, it is more or less a collection of canned, pre-compiled routines (called “class libraries”) that programmers can hook into and use in their own applications so they don’t have to code those routines themselves. Platforms that intend to run software designed around the .NET framework need to have that framework installed so the programs have those class libraries available to hook into.

End users really needn’t have any more to do with it than to have it installed for programs that might need it. Programmers using, say, Microsoft Visual Studio .NET will of course have had it installed along with Visual Studio. Once in the IDE, they will have immediate access to a whole slew of class libraries that will allow them to perform all manner of tasks with a simple call to the .NET functions they require and a few parameters. It’s like having whole chunks of your program already written. The downside of course is that you are relying on the stability and optimizations of Microsoft’s .NET coders which may or may not be the most ideal in the world (and let’s face it, it’s Microsoft; they’ve never been accused of writing svelte, bulletproof code) but it’s convenient if you’re coding on a deadline – or just lazy.

It’s more than just the routines, and you’re probably using it now.

There’s also the runtime engine, which is a partial layer between your programs and the hardware and operating system.

And there are the Windows Forms. When you click on a button or enter text in a text box in a Windows program, you’re using a Windows Form (if it’s a pretty new computer and Windows), or you’re using part of an older and klunkier version of the same stuff.

And, anything written with the current generation of MS programming tools doesn’t compile all the way to machine code, it compiles to an intermediate language that is interpreted by .NET.

I’m not a .NET programmer (I’m thinking about it) - but I think I’m right in saying that one of the features of the design is abstraction (implied by much of what has been mentioned above anyway) - the program you create doesn’t do stuff directly, it makes requests to objects that already know how to do the stuff you want (and in the ideal world, do it safely and properly)

In addition to the above comments - the .NET framework provides (sort of) language independent access to the Windows APIs.

The original Win16/Win32 binary APIs were written in C, so to interface to them, you needed to write applications in C, or modify your compiler/interpreter to use the C calling conventions. This was a major headache for language developers, and meant the reinvention of interface layers for Pascal, C++, Python, Perl, PHP, Uncle Tom Cobbley and all. Not all services would be implemented, everyone did the common things differently, and skills could not be transferred.

The .NET Framework defines a language independent approach for marshalling data (to pass to the binary APIs) and calling services that makes the whole process easier, even if the language is not a CLR (Common Language Runtime) language. It standardises the services and the approach to using those services too, so that learning how to use an interface in Perl helps if you try to reimplement it in C#. Also, you can write a service in Python that can be used from VB.NET or something else.

Finally, the .NET Common Language Runtime executes .NET bytecode. This is a cpu independent intermediate stage between human readable computer languages and cpu level machine code. Language writers can write a language compiler that produces .NET bytecode and supports the .NET framework interfaces. Microsoft have produced C#, VB.NET, JavaScript.NET, others have added IronPython.NET and probably many more. The bytecode files produced by these languages are actually language independent, and can be interfaced with each other. In fact, the bytecode can be directly executed on the Linux Mono implementation of .NET (if no Windows specific interfaces have been used). This feature addresses the total failure of Microsofts original crossplatform approach to NT (MIPs, Alpha and i386 processors). If apps are bytecode and use standard interfaces, then they can run on different hardware platforms without cpu varients - it was the total lack of compiler support (without major code changes) on MIPS and Alpha that meant that no-one released apps for those Windows platforms, including Microsoft.


OK. Let me try to place this into a context that I’m familiar with.

I’ve programmed in MS-Access and PowerBuilder among other things. These two tools have their own sets of pre-written code (classes and objects if you prefer). Each one had command buttons, text boxes, scroll bars, etc. and all you had to do was pull them off the toolbar, drop them on a form, add a little code to make it specific to what you were doing, and off you went.

Since PowerBuilder is not a MS product and Access is, I suppose that the code behind their classes would be significantly different from any MS produced class. But what about Access? Are the Access classes that I’ve been using all these years different from the .NET classes?

OK, but what kind of tasks? Is this something beyond buttons and forms?

Well, that implies that a .NET application won’t run on a machine that doesn’t have .NET installed. Is that right?

Hmmm… Seems I’ve heard this “language independence”/“platform independence” song and dance before. Every few years it seems some ground-breaking cross platform technology is released with great hoopla and always as though it’s the first time it’s ever been done. But maybe I’m just getting jaded.

I’ve written code in the past that used the Windows API to call certain functions, and I believe all I needed to know was what parameters I needed to pass and what to expect the call to return. So unless I’m missing something - and I probably am - I don’t see why we need a whole new paradigm for this.

Yup. The .NET Framework has classes for eveerrrryyything. Threading, encryption, HTTP Communication, and a gazillion more. Just about everything you need to write code for Windows.

True. But the .NET framework comes installed on XP and Vista, so it’s not like that’s a big deal.

Yeah, you’re right. But .NET takes it a step further - it doesn’t get rid of the languages, it just makes them all compile down to the same code. Whether this is good or not is a religious debate.

The new paradigm is easier to understand and code in. Whether or not it’s “needed”, well, once again, that’s a religious debate :slight_smile:

The kind of programming I do is your basic business applications - database apps or the occasional Web site. Threading, encryption and HTTP communication are not things I’ve ever had a need for, or if I had it’'s been handled in the background for me. So for ordinary programmers like me who aren’t writing new languages or building new tools like word processors, what would be the benefit of investing the time in learning this technology? Or is this part of the religious debate you referred to?

To expand on Athena’s observation, we’re talking about things like standard protocols, including CORBA and SOAP, XML handling, image manipulation, data access (including native SQL Server and Oracle stuff), and lots more.

In fact, you can call functions written in any .NET language from any other .NET language. I’m working on a project written in C# that uses vendor-written [.NET] C++ objects transparently.

It is manifestly not for lazy programmers, but it does offer a huge advantage to development shops that are willing to tie themselves to the platform (or platforms, if you consider MONO acceptable) that it’s implemented on.


But I know that our website has gone to .NET programming. It’s made it much, much easier to do things like use windows authentication for secure access to different areas of the website, query backend databases, access network directories and files, etc.

We could do that before using our old web server programs, but it’s much easier in .NET.

YMMV. :slight_smile:

Lots of Windows APIs require parameters that are pointers to structures that are complex, involve pointers to other structures, C style arrays and strings (by value and by reference). In a dynamic or interpreted language (VBScript, Perl, Python, PHP) these are really difficult to construct and pass through. So each language implements a Windows API interface that suits the language. These are often not entirely complete, or not as flexible as the underlying API. .NET regularises all that, and makes it core to the OS/interface. As time goes, I expect more and more of the system will be shifted to .NET assemblies.

In this case, the language independence really does work. I’ve written assemblies in IronPython that can be used from VBScript, and other stuff that works the other way round. I’ve not used Mono, but I hear that .NET apps can be ported pretty easily to Linux (if you use Gnome).

The sorts of Application frameworks that you use to write Business Applications will start to use .NET - all the Office 2007 apps use .NET underneath for the scripting tools and Object interfaces. Other tools will follow. As for Web sites, again the regularity of the .NET interfaces and the flexibility to use the language you are most familiar with to do things should improve productivity. IIS is a .NET framework with exposed object and interfaces, too.

But it should not be hard to learn - .NET feels like OLE on steroids - it’s not a difficult framework to get used to. You just need the help files to figure out what it provides.


Well, I consider myself an “ordinary programmer”, too, and I’ve used the threading, encryption, and HTTP libraries. So I guess it depends on your definition!

The benefit, IMO, is that the .NET framework makes coding most stuff easier and faster than using older technology. I’ve been doing Windows coding since about 1991, and yes, I could do the same things back then that I can do now. The difference is now it takes me 10 minutes to write a multithreaded subroutine and in 1992 it took me 3 days.

Really, you can avoid learning it if you want to, but I don’t see why you would. It makes life easier, makes you more productive, and it’s way cool. If you’re a nerdy computer geek, that is.

If you wanted to, you COULD get Visual Studio Express and SQL 2005 Express for free from Microsoft and use drag-and-drop and not actually have to learn anything about .Net.

I got myself 3 books on the topic in preparation for a project and most of the books were about how to drag and drop stuff around in VS.NET. It’s very intuitive.

You could take yourself further by then understanding and manipulating the resulting codebehind.

.Net is as hard as you want it to be, really. It can do some awesome stuff and MS is making it really accessible to use on many skill levels.

Another way to learn about it is to install SharpDevelop - it’s a free development tool that supports three languages -, C# and Boo - and it translates your code from one to the other any time you like. I had a little play with it and it seems really quite good.

Once upon a time there was a programming language called Java, one of whose main features was that instead of compiling to the native machine code of the machine the program was to run on, it compiled to “bytecode” that would run on the Java Virtual Machine, a special software system you have to run in order to run Java progarms. If you have an up-to-spec JVM for your computer, whatever it is, you can, in theory, run a Java class comiled by an up-to-spec compiler on it, creating instant portability of code.

There are many problems with Java, but the main problem, from Microsoft’s standpoint, was that Java was a product of Sun Microsystems, and you therefore did not have to pay Microsoft to use it. To solve this problem, Microsoft first made it very difficult to do proper Java on Windows*, damaging both the portability and reputation of the language. They then created their own version of the JVM called the .NET platform, and their own nearly-identical version of Java called C#.**

Now the actual neat thing they did was that they changed the compilers in Visual Studio to compile to .NET-native code, which gives incredible versatility. You can create a class in C#, use it and modify it later in VB, etc.

If you are using newer versions of Visual Studio, you are already creating .NET apps.
*details can be found in the “Findings of Fact” section of Federal Judge Jackson’s anti-trust decision against Microsoft, which was specifically upheld by the higher court that threw out that decision for other reasons

**My colleague, until this year when MS cancelled support of the AP Java classes, taught his AP preparatory computer classes in C#, even though the Comp. Sci. Advanced Placement test is given in Java. No students reported any difficulty in switching, that’s how close the languages are.

To add to what Mangetout says, just experiment with the MS development tools and the people who add to them. MS dev tools are really pretty excellent if you are interested in learning stuff for free.

The Vista/Office 2007-oriented betas of Studio 2008 and whatnot are all available for download too.

Cant that at least be partly explained/excused by the fact that Java has C++ in its conceptual ancestry?

In the interest of being clear here, Java was not at all the first language to be interpreted at runtime like described above; the concept has been used since at least the early 80s. Microsoft did not steal this idea from Sun. I disagree with scotandrsn’s description of the .NET compiler being MS’s version of JVM - there are similarities, but there are also many differences.

'tis true, however, that C# is a lot like Java. Then again, Java is very similar to C++, if you forget about pointers. And C++ is a lot like C, if you take away classes. And on and on and on…

C# is really closer to C++ than Java. It also has some traits that it shares with Java that are different from C++, but they’re also shared by pre-Java languages, especially out of academia. In fact, in some ways, C# is the evolution of post-C++ languages that Java should have been.

This is not true at all; I have developers that are maintaining many pre-.NET apps using Visual Studio 2005. In fact, most of them have not yet even looked at .NET.

Hmmm… CORBA, SOAP, XML eh?

Holy Jesus! Is that even English? I have no idea what that means.

I’m just having a hard time seeing where I would ever need any of that stuff. I can almost get excited about the data access functions, but these are typically built into the tools I use and I just don’t see a need to call up special classes just to query a database.

I can see how .NET would be useful to those of you who code at lower levels like C and C++, but for me I’m still not seeing the need.