The codebehind is a powerful ASP.NET feature that allows for the complete division of the Web form GUI design and logic code into separate files. This feature also enables you to create Web forms with Managed C++. Basically, it makes your Web forms accessible via the Internet or an intranet. You must place the Web form’s Managed C++ code logic into a codebehind and then precompile into an assembly. The main steps involved in configuring Visual Studio .NET involve preparation for the creation of these precompiled assemblies. These steps are covered in this article.
Creating a standard class library
The first step in configuring Visual Studio .NET is to create a standard Managed C++ class library. This library is created because a codebehind is really just a library assembly with a few specific coding requirements. As you can see in Figure A, the precompiled codebehind (or library assembly) will be called Greetings. You can use your own naming conventions when creating your codebehinds.
The next few configuration steps are optional, but I perform them because they make the environment cleaner. First, in the Solution Explorer, I rename the Header Files folder to Class Files, since I’m putting class files into the folder. For those of you who prefer the same-old-same-old, these files do end in .h and are included, so they are also header files.
Next, I delete the generated .h file—in this case, Greetings.h—from the Solution Explorer and physically from the development directory, as the file is not needed. I also delete the ReadMe.txt and resource files folder for the same reason.
I don’t see the need for precompiled headers with ASP.NET, so I delete stdafx.h and stdafx.cpp. If you do this, you also need to change the properties of the project’s configuration not to use precompiled headers (see Figure B).
|Project’s configuration properties|
I highly recommend the next optional step, as it will keep your Solution Explorer much cleaner. Add a folder called Web Forms and provide it with a filter of aspx;asax;ascx;config. If you plan to make many Web forms, it would be better to create a whole folder hierarchy. But in the next article, we’ll create only a simple Web form, so this one folder will do.
The following two configuration steps are required. If you do not execute them, your Web forms will not work.
The first step is to change the directory where you created the project into a “Web-shared” directory by providing it with a Virtual IIS directory. There are several ways of doing this, but the easiest by far is using Windows Explorer (see Figure C).
|Creating a Virtual IIS directory in Windows Explorer|
Directory creation involves the following steps:
- 1. Navigate to the source code directory of your library.
- 2. Right-click on the directory folder to get the Properties dialog box.
- 3. Select the Web Sharing tab.
- 4. Select the Share This Folder option to bring up the Edit Alias dialog box.
- 5. Enter the alias you want. I’ll just take the default, in this case.
- 6. Click OK twice to close both dialog boxes.
The next step is changing the assembly Output Directory to the bin directory. This is required because the bin directory is where ASP.NET looks for its codebehinds. If the Greetings codebehind was left in the default Debug or Release directories, it would not be found. You can optionally change the Intermediate directory to build (see Figure D).
It’s possible to create ASP.NET Web forms at this point, but we’re going to add three more files that might come in handy later. The first is the Web.config file, which defines configuration settings that are used when your Web application is first deployed. Listing A contains a copy of a Web.config file you can use. You might notice that it is similar to the Web.config auto-generated for C# or Visual Basic .NET, except that the defaultLanguage attribute of the compilation element has been removed. I also removed the comments to save space. If you create your own Web.config from a C# or Visual Basic .NET version, you can leave the comments in.
The second and third files you should add are the Global.asax file (Listing B) and its codebehind, Global.asax.h (Listing C). The Global.asax file is an optional file that contains code for responding to application-level events raised by ASP.NET. (Incidentally, I created these two listings using my Wfconvert.exe tool, which automatically converts C# Win/Web forms into Managed C++ Win/Web forms. But that’s another article.)
Just to make sure you got everything, take a look at Figure E, which shows how the Solution Explorer should now look.
|Solution Explorer appearance from Listing C|
Where do we go from here?
Now you have Visual Studio .NET configured and ready for the creation of your first Managed C++ Web form. In my next article, I’ll walk you through the process of creating this first ASP.NET Web form with a Managed C++ codebehind. I’ll conclude the series with a third article explaining how to set up your environment for debugging ASP.NET with Managed C++ codebehinds.