This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

  • Article

MSDN Magazine

.NET Beta 1 Arrives

Beta 1 is here!

This month marks a major milestone both in our coverage of Microsoft .NET and for Microsoft .NET itself. The .NET milestone is the public release of Beta 1. For us, it's our sixth issue on the topic and our second big .NET spotlight issue.
      Until we ran our first big feature package introducing the .NET Framework in last September's issue, the topic itself was brand new to most peopleâ€"including us. There were lots of promises about how the framework would make things completely different for programmers. However, it also became clear that .NET would be a vast topic that would challenge even the highest bandwidth developers. Way back in September, we were mostly just trying to introduce some of the high-level features of the .NET Frameworkâ€"how the runtime worked, what C# was, how ASP+ (now ASP .NET) made life easier, and so on.
      There were still a lot of questions to be addressedâ€"questions that could only be answered with hands-on experience. The biggest question of all, of course, was whether the stuff even worked. Well, we've been trying out the Beta 1 release for a few days now, and we're pleased to announce that it's really quite stable.
      Of course there are a few of the typical beta anomalies (most no more serious than placeholders instead of content in the documentation), but for the most part things that we test work the way they should. Since our whole reason for existence is to make it easier for developers to do their jobs, we want to make it possible for you to share this hands-on experience. That's why we're including Beta 1 of the .NET Framework with this issue of MSDN Magazine. When we say that ASP .NET is the greatest thing since sliced provolone, you can follow along to see that we're not just tossing you some marketing fluff.
      Let us say, however, that ASP .NET is the greatest thing since sliced provolone. We've already started using it to streamline our own internal processes. We have an existing editorial calendar that's evolved from a Microsoft Excel application to standard ASP, with a bunch of ADO calls to SQL Server. Recently, we decided to get with the program and rewrite it in ASP .NET. What had been a tedious, chart-drawing and filling proposition turned into a seven-line breeze (not including Dim statements):
  ADOCon = New ADOConnection("uid=xxx;database=yyy;server=qqq;" _
                 & "pwd=vvv;driver={SQLServer}")
DSComm = New ADODataSetCommand("SELECT * FROM ARTICLES", ADOCon)
Dset = New DataSet()
DSComm.FillDataSet(Dset, "Articles")
MSDNMagGrid.DataSource = DSet.Tables("Articles").DefaultView
MSDNMagGrid.DataBind()
      Of course, it's true that MSDNMagGrid, a server-side component of type asp:datagrid, is doing all the work for us. However, figuring out what to do with that component once it was on the form has been made much easier with the browsable, logically arranged class hierarchy that's one of the principal selling points of the .NET Framework.
      There's a lot of work ahead. We've covered the .NET Framework extensively over the past six months, but there are miles of ground to cover. Now that you have the underpinnings of the technology, we'll be looking at specifics. This month we're looking at Visual Basic .NET, Web Services in ASP .NET, Windows Forms, the security structure of the .NET Framework, how to package and deploy .NET-based code, and how to write peer-to-peer applications with the framework. A quick look at the overall hierarchy shows that there is an infinite number of nooks and crannies to explore. It looks like the possibilities of the framework will never be exhausted.
      To give you one example, we've discovered that although the framework is comprehensive, it's not a complete representation of everything that Win32 encompassed. Take serial communications, for example. Last month, we demoed a GPS program that read incoming serial data from a port. Just to keep our brains fresh, we sat down to figure out how hard it would be to convert it to C#. What do you know? There are no System.IO.Serial classes. All hardware communication has to be performed through unmanaged Win32 code. As you look at .NET, you may find a class that you just need to have, but which isn't currently included. And then you'll have a chance to make a name for yourself by writing it for the world!

From the February 2001 issue of MSDN Magazine