ASP.NET, SQL Server, WPF, C#, VB.NET

Howdy, Dr. Dotnetsky here again, with some cool tricks and info to feed yer hungry mind on! Yum!

Removing Advertisements from MSN Messenger 6.0

In order to pay for the service, Microsoft send advertisments in the form of animated images
to all users of their MSN Messenger service. While these do not constitute a security risk or
consume much bandwidth, you may wish to disable them. Microsoft, of course, do not provide an
easy option to do this, but there is a way.

To remove the inline advertisements from MSN Messenger 6.X:

• If MSN Messenger is running, exit the application.
• Open Windows Explorer and navigate to your user profile area. This is usually found in:
  x:\Documents and Settings\username
• From your user profile folder, navigate to:
  Application Data\Microsoft\MSN Messenger
• You may have to enable viewing of hidden files and folders within Tools -> Folder Options in order to see these directories.
• Within the MSN Messenger folder, there will be at least one sub-folder the name of which will be a number. The number corresponds to your MSN Messenger sign-on ID, although not been able to establish the exact connection.
• If you have used more than one sign-on ID, there will be one folder per sign-on used. The following instructions should be repeated for each sign-on folder.
• Navigate to the sign-on folder.
• Using notepad or a similar text editor, open up ConfigCache.Xml.
• Delete the contents of the file between <MsgrConfig> </MsgrConfig> the tags. These tags will be the first and last entries in the file.
• Save ConfigCache.Xml, and exit the text editor.
  In Windows Explorer, right click upon ConfigCache.Xml and choose the Properties entry from the pop-up menu.
• In the Attributes section, check the Read Only tick-box. Click OK to close the Properties window.
• "Tadaa!" --MSN Messenger will no longer display advertisments! Dr. Dotnetsky would not play you wrong, kiddies!

ASP.NET "Low Level" worker request access

Now anyone who reads Dr. Dotnetsky's occasional rants here on the eggheadcafe.com channel knows by now that I think Blogs are for the Birds. However, I did say in a recent babble of mine that there were exceptions, and one that I feel compelled to make mention of is put out by a real thinker, Daniel Cazzulino. Daniel is the guy originally from Deverest fame who, with his buddies, put out some remarkable code at SourceForge called "NMatrix", and he is also the author of the original Wrox book on ASP.NET Server Controls who wrote the stunning "extra" PDF bonus chapter that you have to download separately (which chapter, in the Doctor's humble opinion, is worth more than the entire rest of the book). To paraphrase Daniel's most enlightening discovery:

Sometimes you need low level information about the current request in a web application, such as the IP address of the physical network adapter the request came through (cool in clustered multi-NIC servers), or some other weird stuff you can't find in the higher-level view provided by HttpRequest , HttpResponse and friends.
HttpContext implements IServiceProvider , which means you can ask for services with the following code:

The one thing you can get that there's absolutely NO other way of getting, is the current HttWorkerRequest:

// Get the worker
HttpWorkerRequest wr = (HttpWorkerRequest) provider.GetService(typeof(HttpWorkerRequest));
// Get the NIC address
string addr = wr.GetLocalAddress();

Another very cool use is to retrieve known header values. Usually, you just get the header from the Request.Header collection by its name:

// Would return "Keep-Alive" if enabled.
string cn = Request.Headers["Connection"];
// Would return "gzip, deflate" for example.
string enc = Request.Headers["Accept-Encoding"];
// but that's prone to errors, and you have to sort of guess the casing, etc. This is the cool way:
// Get the worker
HttpWorkerRequest wr = (HttpWorkerRequest) provider.GetService(typeof(HttpWorkerRequest));
string cn = wr.GetKnownRequestHeader(HttpWorkerRequest.HeaderConnection);
string enc = wr.GetKnownRequestHeader(HttpWorkerRequest.HeaderAcceptEncoding);

Now here is a listing of the Class members, for those who wish to experiment further:

Public Constructors

Public Fields

Public Properties

Public Methods

Protected Methods

-- As can be seen, there's a whole buncha cool stuff in there that's not exposed at all by the HttpRequest, HttpResponse and related classes. Cool!

Fixing ASP.NET mappings / bindings

We get a lot of requests from people who have discombobulated (that's geek - speak for "I Screwed It Up") their installation of the .NET Framework or Visual Studio .NET or what not, and ASP.NET doesn't work. 99% percent of the time the ASPNET_REGIIS.EXE utility will fix it. What's THAT, you say? Well you can usually find it here:

C:\WINNT\Microsoft.NET\Framework\v1.1.4322

Just be sure to replace the "WINNT" with "Windows" if on XP and the "v1.1.1.4322" with whatever version of the framework you want to "stick" when you run this. (In other words, don't run the guy in the v1.0.3705 folder if you don't want Framework 1.0 and you have a newer version)

There are a bunch of command line switches on this puppy and I'm reproducing them here for easy reference:

Usage:
aspnet_regiis.exe [-i[r] [-enable] | -u[a] | -r | -s[n] <path> | -k[n] <path> | -lv | -lk | -c | -e[a] | -?]
-i - Install this version of ASP.NET and update scriptmaps
at the IIS metabase root and for all scriptmaps below
the root. Existing scriptmaps of lower version are upgraded to this version.
-ir - Install this version of ASP.NET, register only. Do not update scriptmaps in IIS.
-enable - When -enable is specified with -i or -ir, ASP.NET will also be enabled in the IIS security console (IIS 6.0 or later).
-s <path> - Install scriptmaps for this version at the specified path, recursively. Existing scriptmaps of lower version are upgraded to this version. E.g. aspnet_regiis.exe -s W3SVC/1/ROOT/SampleApp1
-sn <path> - Install scriptmaps for this version at the specified path, non-recursively. Existing scriptmaps of lower version are upgraded to this version.
-r - Install scriptmaps for this version at the IIS metabase root and for all scriptmaps below the root. All existing scriptmaps are changed to this version, regardless of current version.
-u - Uninstall this version of ASP.NET. Existing scriptmaps to this version are remapped to highest remaining version of ASP.NET installed on the machine.
-ua - Uninstall all versions of ASP.NET on the machine
-k <path> - Remove all scriptmaps to any version of ASP.NET from the specified path, recursively. E.g. aspnet_regiis.exe -k W3SVC/1/ROOT/SampleApp1
-kn <path> - Remove all scriptmaps to any version ASP.NET from the specified path, non-recursively.
-lv - List all versions of ASP.NET that are installed on the machine, with status and installation path.
Status: Valid[ (Root)]|Invalid
-lk - List all the path of all IIS metabase keys where ASP.NET is scriptmapped, together with the version. Keys that inherit ASP.NET scriptmaps from a parent key will not be displayed.
-c - Install the client side scripts for this version to the aspnet_client subdirectory of each IIS site directory.
-e - Remove the client side scripts for this version from the aspnet_client subdirectory of each IIS site directory.
-ea - Remove the client side scripts for all versions from the aspnet_client subdirectory of each IIS site directory.
-? - Print this help text.

The most common switches you will probably need to use are -i and -c.

Well, I've got more I could write this time around, but frankly, I just hate warm Martinis, so Ciao! The temperature here is dropping faster than Democratic Candidates in Iowa, so I better get a refresher...