Author's Note: See "Microsoft Computing: Microsoft's .NET Framework" for an introduction to the Microsoft .NET application development system.

OK, we're listening. The .NET platform for Windows application development has gotten our attention, but what are we really going to be working with? I mean, if we adopt .NET, what are we getting ourselves into? That is, what's the big IDE?

An integrated development environment (IDE) is the thing a programmer stares at for hours at a time. It's the screen where the program source code is displayed and edited. It's also where the application's graphical interface and dialogs are designed and created. For iSeries/400 green-screen programming folk, it's like a combination of SDA and SEU: You can both edit source code and design a screen layout by flipping back and forth between the two. When you're finished with your screen designing and code editing, you may compile your application--screens, program, and all.

Understanding What an Assembly Is

To appreciate .NET, it's important that you understand what a .NET assembly is. Briefly, an assembly is a collection of intermediate program instructions that is compiled just in time and run on the user's computer (like Java bytecode.) Assemblies travel under the extension names of ".exe" (just like programs) or ".dll" (just like, well, dlls).

For example, you might have a VB.NET program you're fond of that, say, displays your company's logo in a splash screen, waits for a few seconds, and then ends. Now, suppose you want to write an application in C# (a shrewd and worthy track) and you would like to bundle the VB splash screen program into the same assembly. Since all .NET languages compile to the same Intermediate Language (IL) code, you may combine IL from one project with that from another.

Project Files

Many Windows-level application development packages support the idea of a "project file." To understand what a project file is, please consider the iSeries programmer's plight. In an interactive iSeries application, there are typically a number of participants--some screen formats with source code in QDDSSRC, an RPG program with source in QRPGSRC, and a CL program with source in QCLSRC. Wouldn't it be nice if there was another little file that held entries specifying the names of all the program participants plus the source file and member names? Then, when you took a notion to work on said application, you would simply open that little file, which would identify each of your source code members. The members would then be opened automatically and placed in SEU or SDA, ready for modification. Yeah, that would be cool. That's exactly what a project file is. It's a small text file consisting not of source code, but of a list of source code members (files) that, taken together, represent an entire application. For example, here is an excerpt from a VB6 project file that specifies a module (source code statements) and a six form files (screen formats together with source code statements).

Module=mMain; Main.bas
Form=About.frm
Form=Main.frm
Form=Excel.frm
Form=Splf.frm
Form=Outq.frm
Form=Splash.frm

(In Windowsland, the concept of a file "member" is unknown. Each display file screen format, or form, is a stand-alone entity, and each source code collection resides in one or more distinct files.)

In addition to storing a list of the source files, a project file stores your IDE settings for that particular project, any outside resources you need (like ocx controls), your compile-to directory, etc.

Once your modifications are complete, it would also be nice to just say "compile" and have the screen formats, the RPG program(s), and the CL driver created. Yep. You guessed it. Most Windows application development IDEs can do that, too.

Solution Files

And yet, there's an even higher view one can take over a .NET application. Since the .NET Framework allows assembly of program instructions from any .NET-centric language (C++.NET, VB.NET, C#, or J#), you may use any or all .NET languages in the same assembly. That is, in the IDE you may specify a VB project, a couple of C# projects, and a J# project all under the same roof, called a "solution." A solution is a collection of projects, just as a project file is a collection of source code files.

The Visual Studio .NET IDE

I recall the first time I opened a software package like the .NET IDE. There were so many panels, windows, tabs, explorer trees, and buttons (especially the buttons--it looked like one of those trucks with too many lights bearing down on you) that I was overwhelmed. I didn't know where to begin. Did I really need all those things? I thought that if I could determine which of the panels were more important than others, I might be able to pare it down to those, thus reducing the confusion.

Because a contemporary IDE system addresses a number of aspects of programming, it is necessarily complicated. An IDE like .NET supports form design, source code editing, context-sensitive help, compiling, debugging, error reporting, documentation generation, and even a programmer "to-do" list. So let's hit the highlights in hopes of sorting it out a bit.

For illustration purposes, an example .NET application that ships with the Visual Studio SDK will be loaded into the .NET IDE. The project is called SimpleHelloWorld, and source code is shipped for both C# and VB. Figure 1 shows the .NET IDE after SimpleHelloWorld for C# has been loaded.

Figure 1: This screen shows the .NET IDE with the SDK sample SimpleHelloWorld project loaded. (Click images to enlarge.)

Remember, the .NET IDE is a combination of screen design tools coupled with a slick source code editor. At letter A, the IDE is showing the screen design part of the IDE, called the "design view" window. The form displayed in the design view window is blank but is presented by the IDE in anticipation of becoming the first form of your GUI application.

The items in the list in the toolbox at letter B are called "controls." Controls are the things you place on an otherwise blank form to create a GUI application, such as labels (which are like constants on a iSeries screen) or text boxes (which are like iSeries input/output capable fields). Or you might add a command button or two or even some check boxes. By dragging and dropping labels, text boxes, command buttons, etc. onto your form, you turn the blank form into one suited for your application.

The toolbar at letter C is collection of shortcuts for common IDE tasks, some of which you are no doubt familiar with (opening, saving, undoing, getting help, etc.). I wouldn't worry about the unfamiliar ones just yet; they will become more meaningful once you become accustomed to the moves made within an IDE.

The Explorer-like window at letter D is called the "Project Explorer." It gives you a rundown of the files that are in use by your project. Recall that a project file is a list of source files used in a programming effort. The project file is read by the IDE, and each of the participating source files is then opened and included. You edit source code or design a form for only one of these files at a time, and the Project Explorer allows you to keep track of them.

Finally, the remaining window at letter E is called the "Properties Window." Properties are like display file attributes in that they further describe a particular appearance or behavior of a form or control. That is, the .NET property "visible" is like the iSeries display file attribute "non-display" in that it controls whether a field is shown. Normally, the properties window will display the settings for the control that has the "focus" (that is, the one you clicked on last.)

OK, so what have we got so far? The IDE is showing us a place to create forms by placing controls on them. Once there are some controls, we can tailor the behavior of the controls through their properties settings. We then save the source code for the form and its attendant controls in a file, the name of which is displayed in the Project Explorer.

Creating .NET Source Code in the IDE

Well, there's usually more to creating an application than just designing some screens, so we're going to need a place to edit some source code. Figure 2 shows the .NET IDE in source code editing mode (the tab at letter A was clicked to bring up the source code for the form.)

Figure 2: This is the source code editing window of the .NET IDE.

The panel designated by letter B is where your source code statements are written and edited. Notice the controls toolbox (at D) is now blank, as is the properties box (at C). That's because neither controls nor properties are appropriate when editing source code.

Intellisense

In Figure 2, letter E, there is a small panel that can contain a list of programming tasks that have yet to be performed, such as correcting syntax errors. Figure 3 shows the code editor and the tasks list when there is an outstanding error.

Figure 3: The IDE source code editor shows a syntax error.

The syntax error is at letter A, where a parenthesis is missing. Note the little squiggly line under the semicolon, indicating there is something wrong at that location. The task list (B) identifies the nature of the problem, which is ") expected," and the line of code in error, which is 17. Further, if I were to double-click the task list item, I would be shuttled to the scene of the source code crime. This feature of the .NET IDE is called "Intellisense."

AutoComplete

Perhaps the coolest part of a good IDE is all the help it gives you--not just direct access to the Microsoft Developer Network, but a built-in knowledge of the language at hand. This feature of the .NET IDE is called "AutoComplete" because the IDE will try to detect which expression of the programming language you are working with and offer help. For example, in Figure 4, I've started keying the name of a C# statement "Console" and then keyed a period.

Figure 4: Intellisense interprets your statements as you key and offers suggestions.

AutoComplete, operating constantly behind the scenes, has detected my intent and has opened a listbox of all the things that are part of the Console statement, allowing me to simply select from the list. This is especially important if you are new to a .NET language because you only have to "half know" what you want to do. Then, with AutoComplete's help, you can figure it out.

Now, if you're an experienced C++ or Java programmer, check this out. In Figure 5, I've keyed the name of a .NET interface--IComparable. The .NET IDE has identified the name as an interface that I intend to implement and has popped up the little yellow tip box that says "Press TAB to implement stubs for interface System.IComparable" (letter A). What this means is that if I press the tab key now, the IDE will generate the implementation of the interface and place it in my source code for me (letter A in Figure 6.)

Figure 5: The IDE is offering to create the implementation of the IComparable interface.

Figure 6: The IDE creates the implementation of the IComparable interface and creates a "to do" reminder.

Notice also in Figure 6 that the task list shows a reminder to flesh out the CompareTo method. It doesn't get any cooler than that....

Please bear in mind that I've only touched on the highlights of the .NET IDE. Several other features remain undiscussed, such as dynamic help, AutoHide of windows to save space, Hide and Show code by region, Common Task Automation with macros, and Tab Dock to consolidate windows.

A friend once said, "You don't write programs; you do programs." As you gain experience with the .NET IDE, you will come to rely on the inherent intelligence of such a capable programming assistant and will no doubt wonder how you ever got along without it.

Chris Peters has 26 years of experience in the IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries/400 Report Downloader. Chris is the author of The OS/400 and Microsoft Office 2000 Integration Handbook, The AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400 (MC Press). He is also a nationally recognized seminar instructor. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..