This applies to Windows Server 2003. This error can occur when you have .NET 1.0 and .NET 2.0 applications running on the same server.

This particular error can occur when you haven’t selected .NET 2.0. in the application settings.

Windows 2003 Uses Application Pools which can only support one version of the .NET framework at a time. If you are running both 2.0 and 1.0 applications on the same 2003 server then you have to create at least two application pools - one for each version of the framework. All of your 1.0 apps should be configured to use one pool and the 2.0 apps will use the other. The pool itself isn’t configured to specify which version it will support, but the app that starts first will “grab” the pool and lock it down to whatever version of the framework that particular app uses.  So if you have a 1.0 and 2.0 in the same pool, it will be a race between the two apps to see which can grab the pool first.  The winner will run fine and the loser will crash.  When IIS restarts, the race starts again.

Share This

This perplexing error message recently started to occur in .NET 2.0 applications when adding log4net information within the web.config file as shown in the documentation. The source of the problem seems to be related to the visual studio XML validation and isn’t specifically a log4net problem. More information about the error can be found on this MSDN thread. The only solution that seems to have worked for anyone is to uninstall and re-install WinFX (.NET 3.0 framework).

This error is particularly frustrating because there are hundreds of example configurations for log4net posted online. However many of them are using older versions of both log4net and .NET itself which is not always mentioned. As it happens, there’s another way to configure log4net which doesn’t solve the web.config issue, but is very easy to implement. This configuration works using .NET 2.0 and log4net 1.2.10. Instead of putting the configuration in web.config, you just create an ordinary xml file with your log4net configuration and initialize the logger from this file instead of web.config. This has an added advantage that you can modify the logging settings without having to modify web.config (which typically restarts the application).  The negative to this method is that file permissions must be set to allow read access to this config file.

To configure log4net this way:

First create a new xml file. The name is not important, but the file permissions must be set so that the IIS worker process can read it. Put your <log4net>…</log4net> code that which would normally go in web.config in this file. An example of this can be found at this page (scroll to the section “Reading Files Directly).

If you don’t have a Global.asax file, create one. Within the Application_Start event handler method, place the following code:


log4net.Config.XmlConfigurator.Configure(new System.IO.FileInfo(Server.MapPath("log4net.xml")));


For the sake of simplicity, the logger file in the example above is called log4net.xml and is located in the root of the web application. For security reasons you may prefer to put this somewhere else. If someone knows the location of this file and can access it through the browser, they will be able to see your configuration which will show the location of your debug output. Worse yet, if you are logging to a DB your connection string will likely be in there.

Note that XmlConfigurator.Configure is used instead of the deprecated DOMConfigurator.Configure (per the docs as of log4net 1.2.10). This will load the logger settings once on application startup. You can optionally use XmlConfigurator.ConfigureAndWatch instead which will tell log4net to watch this file for configuration changes. Obviously there would be some overhead in doing this.

One additional thing worth mentioning is that log4net will not complain at all if any of the file paths you give it do not exist or do not have the proper permission.  It will simply just not log anything.  This can be frustrating as well so be sure to carefully check all file paths and permissions.

I hope this post may have saved you some time and frustration. If you have any additional information, please feel free to post a comment.

Share This

If you are a .NET web application developer and you install Cincular Connection Manager, you’ll be in for a treat when none of your .NET web applications will run anymore! When you try to connect to one, you’ll hear a windows alert beep, but will see no error message displayed.

The solution at the moment is to not install Connection Manager. If you uninstall Connection Manager, the good news is that your web apps will all go back to normal and will work again. whew!

However, you really don’t need the software to use your Cingular cell phone to dial-up to the internet. You can simply create a new Dial-Up account. Select your cellphone as the modem and then enter the following for the dial-up parameters:

number to dial: *99***1# -or- *99***2#

(the number 1 or 2 depends on what order your cellphone shows up in your list of modems. it might even need to be 3?)

username: ISP@CINGULARGPRS.COM (case sensitive)

password: CINGULAR1 (case sensitive)

You can just dial-up through your cellphone as if it were a regular modem.

You have to have the data connection added to your cellphone plan for this to work at all, by the way. You also have to have your cellphone connected using the data connection cable or bluetooth and the correct drivers for your phone need to be installed. You’re on your own for that part!

Share This