On a recent project, I had to learn and develop some code using .NET. This was my first experience using a Microsoft framework for anything. I wouldn't call it an entirely pleasant experience, but it was also not entirely unpleasant. I want to talk a little bit about my experience with it, and mention a couple things that might help other people getting started with it.

This information should be reasonably current, although admittedly it's been several months now since I was working on the project regularly. If you find mistakes, do let me know. I was using .NET 1.1.

For cost reasons, I wanted to build this application without Visual Studio, the IDE Microsoft sells for a pretty penny that makes your life in .NET easier. (Apple, for the record, bundles theirs (XCode) with the operating system.) Microsoft does give away the .NET Framework, and its SDK, for free. A big deal was made in the materials I read that it was free, that you didn't need to buy anything to develop for .NET. In my experience, though, it turns out to be rather difficult to find practical information on how to develop web applications with .NET, but without Visual Studio. The only article I found when I was getting started on my project was a fairly basic one from O'Reilly.

There are many tools available that are free and might replace Visual Studio as an IDE, but nothing I saw that includes a really great editor (the one in Visual Studio is allegedly pretty nice) along with the compilation and assembly management tools. I ended up using BBEdit on my Mac, opening the files over a shared Windows volume for editing.

.NET is not a programming language, it's a set of developer tools you use to make applications of various types (web, desktop, and so on). You can use any of many programming languages with it -- I chose C# because I have more recent experience with languages that use C-like syntax. I ended up having to use Visual Basic .NET as well. It makes no difference to .NET itself what you use -- I had to use Visual Basic because one third-party software library we were using (not mentioned in this article) was not fully upgraded to .NET, and was tightly bound to Visual Basic.

** .NET Gotchas **

This is a list of problems I faced, and their solutions (or possibly hacks or workarounds). These will prove mostly helpful to people coming to .NET from something else, and maybe expecting to be able to work in a way their used to. If this spares a few head-size dents in your wall, I'm happy.

• It's my understanding that .NET scripts are compiled, not interpreted. The .NET SDK includes compilers for C# and VB that you must have in order for your scripts to work. If you download just the .NET Runtime, you'll have some compilers, but not everything you'll want. So make sure you get the full SDK.

• If you're moving from a language like PHP, where it's common to interleave bits of HTML and bits of PHP, you'll find things a bit different with .NET. Code and user interface (or presentation and business logic, if you prefer) are typically kept very much separate in .NET. The mechanism they use for this is "codebehinds". A codebehind is a source file containing your Visual Basic, C#, or whatever, code, and it's referenced from your .aspx file. .aspx is one of many file extensions that indicates a .NET file. The Windows web server, IIS, when configured for use with .NET, will recognize the extension and pass those pages off to .NET for compilation.

• As I was developing my app in the form of text files (as opposed to a Visual Studio project), I just wrote some code, then loaded my .aspx files in a browser to see how they worked. I discovered that codebehinds work differently in VB and C#. If you want a script to be compiled when loaded, the lines you use in your .aspx file are:

  C#: <%@ Page Language="C#" Inherits="MyClassName" Codebehind="MyClassName.cs" %>
  VB: <%@ Page Language="VB" Inherits="MyClassName" Src="MyClassName.vb" %>

• One of the requirements of this project was that I use eConnect, a .NET assembly (their term for shared library -- a bunch of code that can be plugged in and used in other software). Normally, with Visual Studio, if you want to use an assembly, you just attach a reference to it somewhere in your project's assembly list or whatever, compile, and it works. Without an IDE, you have to figure out how to do that just in your code. This has two parts.

  First, there are the lines of code.

  C#: using Microsoft.GreatPlains.eConnect;
  VB: Imports Microsoft.GreatPlains.eConnect

  Second, there is the location of the assemblies. I installed eConnect in the Global Assembly Cache, the central location on Windows for all .NET assemblies that are intended to be shared among various applications. That was not enough for my project. Rather, it was not help at all -- my scripts couldn't find the eConnect assemblies. The trick is to install/copy the assembly files (assemblies are .DLLs or .EXEs) into a folder called "bin" in the directory where you code is, or at least somewhere in your IIS root.

• It appears that more than one codebehind file may not be referenced from a single ASPX script. That's a bit unfortunately for easy modularity. I assume Microsoft expects developers to build their shared code into assemblies. That was too much work to figure out in the time I had available. However, you may define more than one class in a codebehind file, so at least copy/pasting a class that's identical to multiple files is doable. It's not a great solution, but it might work in a pinch.

I'm sure there were many other things I ran into during the project, so as I remember more things, I'll update this article.