Clemens Vasters

December 21, 2006

@ 06:56 PM

ASP.NET's autoEventWireup="false" page config setting breaks ASP.NET Web Services (ASMX): NullReferenceException

I've spent the last 1 1/2 weeks doing one of the most fun (seriously) work assignments that each Program Manager of our team gets to do every once in a while: Servicing. So until yesterday night (I'm flying home to Germany today) I was in charge of ASP.NET Web Services and Remoting. An even though these technologies have been out there for quite a while now, there are still situations where stuff breaks and people are scratching their heads wondering what's going on. Overall, it was a very, very quiet time on the bug front though.

The one issue that we found on my watch is that you can configure ASP.NET Web Forms in a way that it breaks ASP.NET Web Services (ASMX). We are shipping one ASP.NET Web Page (.aspx) with ASMX and that unfortunate interaction manages to break that exact page with an error that's hard to figure out unless you have substantial ASP.NET knowledge and you have enough confidence in that knowledge to not trust us ;-)

If you globally override the autoEventWireup setting in the <page/> config element in the ASP.NET web.config and set that to "false", the DefaultWsdlHelpGenator.aspx page (which sits in the CONFIG directory of the Framework) becomes very unhappy and fails with a NullReferenceException, stating "Object reference not set to an instance of an object." and showing you some code that's definitely not yours.

What happened? Well, the file is missing a directive that overrides the override of the default. The fix is to go edit the DefaultWsdlHelpGenerator.aspx file and add the line:

<%@ Page AutoEventWireup="true" %>

That will fix the problem.

Now, the big question is: "Will you put that into a service pack?". While there's obviously a bug here, the answer is, in this particular case, "don't know yet". Replacing or editing that particular file is a potentially very impactful surgery done on the patched system given that the file is there in source code and in the config directory because you are supposed to be able to change it. Could we touch changed files? Probably not. Could we touch unchanged files? Probably? So how would you surface the difference and make sure that the systems we couldn't patch would not suffer from the particular bug? What's the test impact for the code and for the service pack or patch installer? How many people are actually using that ASP.NET config directive AND are hosting ASMX services in the same application and/or scope? Is it actually worth doing that? Making changes in code that has already shipped and is part of the Framework is serious business, since you are potentially altering the behavior of millions of machines all at once. So that part is definitely not done in an "agile" way, but takes quite a bit of consideration, while it takes just 10 seconds and notepad.exe for you.

Categories: ASP.NET | Web Services

« "Google kills SOAP!" | Home | Doug got email. »

Sunday, December 31, 2006 12:33:09 AM UTC

We're one of the companies that's run into (and reported) this exact problem; we are hosting a web service in the same context as our web forms, and due to legacy considerations (hopefully to-be-cleaned-up in the future, but who knows) we need autoeventwireup=false. I would say it's better for Microsoft to fix this, for a couple of reasons.

1. The page in consideration does not appear on all computers, even all computers with both IIS and ASP.Net installed. I don't know why, and everything seems to work fine even if it's not there, but if it *is* there and does not contain the autoeventwireup directive, it breaks. Nobody but Microsoft really knows the exact conditions under which that page is or is not installed.

2. In order for our app to work properly (i.e. at all), that directive has to be there. That means that we either have to require end-users to open a .aspx file and conditionally copy/paste programming code (e.g. Bad Idea), or have our installer do it. If our installer does it, we have to write code to see if it's already been modified, if it exists, etc etc. If every ISV does this, then that's several thousand copies of the code, many potentially buggy, many potentially colliding. If Microsoft does it, it's written once, tested, and nobody else has to worry about it.

For now, we're having our installer do the work, but without spending a lot of time understanding all possibilities and writing a very complex routine to edit the file without removing other customizations, that solution makes me very unhappy. I know Microsoft has a lot of other priorities, but I really think that this is a significant bug and should be fixed even on existing installs.