Beware of Nested Web.Config's!

Problem with Nested Web.Config's
If your web servers host a complex IIS tree, beware of nested ASP.NET applications and their respective web.config's. If a "parent" ASP.NET application declares a type (and therefore a dependency on an assembly), the "child" application inherits this declaration. See the following msdn article for lengthy discussion.

What this means, ultimately, is that your child application will be looking for a dll in its /bin folder. When it doesn't find it, the child application throws a yellow screen.

Here is an example. I've set up http://localhost/MyApp, a do-nothing app that happens to implement the ASP.NET 1.1 URL Mapping Module discussed in a previous blog. I've built another do-nothing app, and for demonstration purposes created a virtual directory hosting this app under the do-nothing parent, http://localhost/MyApp/MySubApp.

See what happens when I try to run the child app from a browser...


Solutions
To resolve the error above, you can take one of the following approaches:

1. Copy the assembly to the child's /bin folder. This works, but it's sloppy configuration. Why xcopy dll's across your file system, introducing redundancy and superfluousness?
2. GAC the assembly. That way it's available to the child, and any other application, whether or not it's needed.
3. Restructure IIS to avoid the problem.

SourceForge.NET's Telnet Library Rocks

Say you need to test your web server's basic connectivity to its SQL database server, or its Oracle database server, or its SMTP mail relay host, etc. You would want to hop on the web server, open a command line console (DOS prompt), and try to connect using telnet commands like:

Telnet mySQLServer 1433

Telnet myOracleServer 1521

Telnet myMailServer 25

etc.

What if you don't the necessary access to log on to the web server? That's the problem I have been facing. Our data center was outsourced, servers moved, and stuff stopped working. If your web application doesn't have the basic connectivity we all take for granted, it's not going to tell you your firewall rules are all mucked up; it's just not going to work.

Enter SourceForge.NET's Telnet .NET library. Download this library, add it to your application's references, write a simple web form that tests remote host and port combinations from user input, and you have a helpful diagnostics tool. It is presently saving my life.

Attaching Lotus Notes links to Outlook Mail

My company has migrated from Outlook/Exchange to Lotus Notes, then back to Outlook/Exchange. With the latest migration away from Notes, we left some vital Notes databases in place. So now we use Outlook for mail, and Notes for repositories.

...Yeah, it's that kind of place. If you've been around awhile and know where things are, you are indispensable :).

Anyway, the great thing about using Notes for email and work was that you could embed all kinds of referral links in your email using "copy as link" at the Notes data and then ctrl+v paste in the email. The ctrl+v doesn't work in Outlook, which is a drag. So here's a work around...

Step 1 - Copy as Link
Go to your Notes document or database (shown below), right click and select "copy as link"

Step 2 - Paste Ctrl+V to a Text Editor

Note the interesting markup

Step 3 - Save the Text File with an .NDL Extension

Step 4 - Attach the .NDL file to your Email Message

...as shown. When the recipient double-clicks the attachment, they go right to Notes!

VS.NET 2005 - Where are the Binaries?

VS.NET 2003 - /bin Directory
In VS.NET 2003 when you set up a web application, an IIS virtual directory was automatically created, most commonly pointing to a file system folder in c:\inetpub\wwwroot.


When you compiled your application, a single binary, appname.dll, was created in c:\inetpub\wwwroot\appname


VS.NET 2005 - Where did the Binary go?
If you just started developing in VS.NET 2005, you may be oblivious, happily leveraging your new master pages and themes. Just wait until you try to deploy your application to another server. You'll come to find:

1. While developing, your application was running under Webdev.webserver.exe, not IIS.
2. There is no /bin directory. In fact, there is not c:\inetpub\wwwroot\appname directory.

To find your development artifacts, visit C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files . The structure may confuse you -- it's more esoteric then appname/bin probably consisting of files with a .compiled extension. VS.NET 2005 has a new compilation model, a subject for another day.

To move your application into IIS:

1. Use the Build/Publish Website interface to create a "release directory".
2. Create a virtual directory that points to the release directory.
3. Make sure the virtual directory is configured to run under ASP.NET 2.0

ASP.NET 1.1 - URL Mapping

A previous post described how to set up simple URL Mapping in ASP.NET 2.0. To do the same in ASP.NET 1.1, it's almost as simple, if you use Chris Pietschmann's code and instructions.

Just add the custom HTTPModule's dll to your application's bin folder, then tailor your web.config appropriately, and you have what ASP.NET 2.0 provides!

ASP.NET 2.0 - URL Mapping

ASP.NET 2.0 provides features supporting "vanity url's" or "friendly url's". These are useful when you want to distribute simple url's to customers.

Say for instance you have an online store, offering a new product to a segment of customers. The path to the catalog item is

http://AcmeCorp.com/store/catalog.aspx?productid=TY3466a&customerid=143044&branch=south

But you'd like to distribute a simpler url:

http://AcmeCorp.com/store/MultiVitamins.aspx

URL Mapping makes this possible. The following is a much simpler example. Note that it just happens to use the location appSettings overrides described in an earlier blog.
The highlighted section specifies the url mapping. The vanity url's (Diablo_Config.aspx and Diablo_Config.aspx?loc=test) are actually just as complicated as the actual paths (testconfig.aspx and test/testconfig.aspx), but it illustrates what's possible. The following screenshots illustrate what the "customer" sees:


The aspx page that outputs the appSettings is simply copied to the application root and /Test folder for illustrative purposes. If you're interested in aspx (not code-behind) that references app settings, see the following link.

ASP.NET Deployment Error

Every seen the following error? It is literally littering Microsoft's ASP.NET forum:

It happens when a developer tries to deploy their first ASP.NET application to an ISP's or employer's shared web server environment. Take a close look at the graphic above, particularly the highlighted section. It's a helpful clue, though in most cases it's not exactly correct.

What's most likely is that the application folder was copied to the site on the production server, without configuring the folder as a virtual directory at all. See earlier IIS posts on automating the creation and configuration of virtual directories with VBScript. You can hand these off to your site administrator.

"Shredding" your Outlook Documents

Have you ever used the "Tools/Recover Deleted Items..." option in Outlook? A friend tipped me to it earlier this year. If your company uses Outlook for email, get familiar with this option and use it often to clean up after yourself. You don't need to keep personal (or worse yet, incriminating) emails within easy reach of an Outlook administrator.

Deleting Items
You delete email all the time, and are probably familiar with the Outlook "deleted items" folder: (deleted items folder)

To clear space for you mailbox (most administrators enforce a size limit) on the mail server, you probably clear this folder routinely. You do this by deleting all items from the "deleted items" folder, kind of like clearing the recycling bin on your file system.

(emptied deleted items)

Clearing Deleted Items, for Good

To remove the items "for good", go to the Tools/Recover Deleted Items menu option and delete all Outlook documents for a third and final time. The "X" icon takes care of it for you. CYA!

C# Console App Displaying Remote ASP.NET Configuration

The following code, when compiled in a C# console application, will print the AppSettings collection for a remote machine. It accepts 4 arguments:

1. Machine Name - the network machine you wish to query
2. Site Name - the IIS site node you wish to query
3. User Name - user id to log into the remote machine
4. Password - user password to log into the remote machine

Notes

The app uses System.DirectoryServices.DirectoryEntry to navigate the IIS Tree and recurse through virtual directories, seeking configuration

The app uses the static WebConfigurationManager class to open and read the AppSettings collections

The main function is overloaded such that user name and password are optional. When not supplied, the logged in credentials of the executing machine are used.

In order to read remote configuration, you must run "aspnet_regiis config+" on the remote server.