Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Nov 12, 2010 01:08 AM by matrat
Jan 20, 2008 03:35 PM|LINK
MS has contacted me, and indicates that they feel this is in fact an error in ASPNET (and not Cold Fusion). Wildcard mappings are allowed and CF correctly redirects as it should. My apologies to Adobe.
MS will be working on a hotfix for this problem. When it is available I will also let you know here.
Apr 10, 2008 03:30 PM|LINK
Update: Scott Guthrie help me to get in contact with Steve Molloy and Matt Gibbs at Microsoft about the original issue in this post (Read more about
The WebResource.axd handler must be registered in the configuration to process this request - not related to Vista or Cold Fusion).
Steve has been running this in the stress lab for a couple days. After several hundered machine-hours of stress while touching config every 3 minutes they have not been able to reproduce the issue.
This is probably a race condition that occurs because the framwork or application we have does something special. But I have not been able to create a simple reproducable test case. Has anyone?
I have identified several things that increases the probability to get this issue:
EnsureHandlerExistenceChecked will called because Webresource.axd is used)
* You have a lot of assembles in your bin folder.
In my case, the framwork I use (EPiServer), has code that loads all assemblies in the bin folder in the constructor of the global.asax class. It does this because it looks for classes with plug-in attibute. This in combination with the call to
EnsureHandlerExistenceChecked on the start page does probably increase the risk for the problem.
Read more comments about "The WebResource.axd handler must be registered in the configuration to process this request" in my
May 18, 2010 08:58 PM|LINK
I believe you are mixing up the question, which has to do with Cold Fusion, and your solution which has to do with EPiServer. Although a similar problem, they apparently are not quite the same since ColdFusion does not touch the Web.config.
A Cold Fusion installation adds serveral default handlers in the machine.config (Custom-AboMapperXXXX) which then are applied to ALL sites on the box, whether these are ColdFusion or not. These are NOT added to the Web.config file and can not be found there.
However if you look in the IIS7 administration under http handlers you will find all of these Custom Mappers (including the culprit - the wild card mapper "*.*) at the top of the list.
Possibly, adding the WebResource.axd handler in the Web.config could work here too, if it then is processed first (which seems to be your claim). That could solve Rich's problem. I haven't tried that out but might be able to next week.
I have solved the problem differently. Since it's not really the best practice to combine a ColdFusion and DotNet application in one app pool, I moved the DotNet web application into a separate application in the same web site which allows me to assign it
it's own application pool. Now I can remove the ColdFusion http handlers for this application (just remove them in the administrative tool for the application) which in fact will create "remove" entries for these mappers in the Web.config. That way the DotNet
web application is running "clean" without interferance from the Cold Fusion mappings AND Cold Fusion can also run in integrated mode in it's own application pool with no interference.
The only "Gotcha" on this is when an update to the next version of Cold Fusion is made, because the name of the mappings (the number of the mapping) is changed then. At that point you have to clean the Web.config and redo the removal of the handlers.
BTW, this problem is still the same with the latest Service Packs, DotNet Frameworks and Cold Fusion versions, so I guess nobody really wants to solve it differently.
I wrote this at home with being able to look at the actual installation, so my description / names may be a bit off, but you should get the gist of it. If not post again and I will look into the actual installation.
May 18, 2010 11:42 PM|LINK
Yes, my research and solution is applied in the scope of EPiServer CMS but after reverse engineering asp.net a little I'm pretty sure the issue is related, so that is why I decided to share the information here.
It would be nice if someone with ColdFusion installed could confirm that adding registration of WebResouce.axd handler again before the wild card mapping would solve the problem.
I'm sure that the Developers behind ColdFusion could patch this the same way as the developers behind EPiServer CMS did. The indication I got from Microsoft is that it is as designed and not a defect - and it can be workedaround with correct configuration.
May 19, 2010 05:17 PM|LINK
don't get me wrong. I am very glad that you answered. It is quite possible that your answer is a better solution than mine was / is. I didn't have time to test it today on our staging server. I hope I can try it in the next few days.
I don't like the answer "by design" at all. Especially if "anyone" (meaning Adobe or EPi) can with a simple installation destroy an uptil then perfectly functioning server. The Adobe installation affects ALL Sites on the server whether they are using Cold
Fusion or not! I should not have to proactively change my ASPNET configuration just in case someone else decides to install another product. When you are the man who did the install for someone else, you could be in a real bad hurt if you don't find the solution
very quickly. I agree that Adobe MUST change their installation, but MS should also protect IIS as far as ASPNET is concerned. We just finished installing the last CF version and it destroyed the configuration of the ASPNET applications. See my post above,
we had to redo the removing of the CF custom mappers.
I will definately try your solution since that could take care of that problem. I still don't like the fact that I would have "foreign" handlers in my ASPNET pipeline though. Who knows what the next problem could be where some other ASPNET handler is masked
by a CF handler (that I neither want or need). My solution takes them completely out of the pipeline for my application.
Jun 10, 2010 12:13 PM|LINK
So now I have had a chance to try abit on our staging server.
As far as the Cold Fusion problem is concerned there is no solution that I can find using the web.config (IOW with a local solution). I tried removing the CF WildcardMapper and the AssemblyResourceLoader in order to add them back two lines later, trying
to influence the loading order (as suggested by Fredrik). Regardless of what I do, the ASPNet application can not run in integrated mode if the WildcardMapper is loaded (anywhere).
Cold Fusion alters the applicationHost.config and adds serveral handlers (10) at the end of the system.webServer / handlers section. These are inherited by every web site that you create. Even though they are at the end of the handlers section, the presence
of the cfm WildCardMapper effectively prevents running an ASPNet Applicationpool in integrated mode. Other than removing that handler (actually I remove all CF Handlers but actually only the one is the problem here) in EVERY ASPNet application I can find no
Regardless of who is fault, I can't understand why MS allows CF (or anyone else) to make such a destructive change (out of ASPNet perspective) at this level.
If anyone else has a better solution, I would be glad to hear it since the next CF Upgrade will again require manual changes to each ASPNet Site.
Jul 30, 2010 06:50 PM|LINK
I tried setting all the apps to classic to no avail.
I tried the things in this thread and none worked. I uninstlled ColdFusion 9 and the problem went away. Thanks for the idea Alle.
I got the errir running the Hello World from Azure tutorial in VS 2010 on my Win 7 x64 dev machine. Since I was running the app from devenv, and I believe it runs in the default app pool and with a port number, I could not avoid the problem by moving the
Azure .net app to a separate app pool. Neither, could I figure out how to move my CF apps to another app pool.
In a production environment I alway use a separate app pool for my apps, so it should not be a problem.
I was done with my CF development for now, so it did not hurt me to simply remove CF. If I need it again, I will reinstall. In the meantime, I am working with Azure and hello world now works in the local app fabric.
Jul 30, 2010 09:50 PM|LINK
First of all, I assume you know that VS 2010 does not use IIS by default but instead uses an internal page server (aka Cassini) which is why you are getting the port assignment. This is not the IIS installation but is probably affected by the same Cold Fusion
handlers that are bothering IIS.
If you have installed IIS in your WIN 7 (it is not installed by default, but is probably installed since you had Cold Fusion installed) you should find that you can create a virtual application (like a virtual folder but with an app pool) in your root using
the IIS Manager. In fact, with Windows 7 you should be able to create a separate site in IIS (which was not possible in XP). Point your VS 2010 web app at that virtual app or site for deployment instead of using the default page server. (Project properties)
In the IIS manager, no matter which method (separate site or virtual app) you can set the properties of that app/site. There you can create an additional app pool and assign the pool to your site / virtual app. Leave Cold Fusion in the default pool. You
can also (and will need to) change the handler setting in the IIS Manager to remove the CF wild card handler mentioned above ONLY for the ASPNET sites / virtual apps.
At that point CF and ASPNET should both work at the same time.
Aug 01, 2010 04:28 PM|LINK
I pretty much knew all the things you mention. And yes, I had IIS installed. I wanted it for CF. I did not know about setting the VS2010 project properties to use a virtual app or site.
I have often wanted to do that. In the past I have had the web app running well on my dev machine and had it fail for some reason on deployment. For this reason, I would rather run the dev under a separate IIS than the default page server. I used to dev
with Server 2003 for this reason.
I will make the change in my devs now and that way, if or when, I need to reinstall CF, I can do the rest of what you suggest.
Your suggestions were very welcome.
Nov 12, 2010 01:08 AM|LINK
I came across this problem when upgrading to a new server. I moved from Cold Fusion MX to Cold Fusion 9, IIS 6 to IIS 7.5. Glad I found this thread... I thrashed for days.
Moving the WebResource.axd handler to the top of the list did nothing to correct the problem. The only thing that worked was running ColdFusion in a separate Application Pool and then removing the AboMapperCustom-xxxxxxxx mappings from the .NET application
pool. FYI - I was unable to get CF to run in Integrated mode, only Classic.
Would really like to see Microsoft fix this problem. My application is a hybrid. I originally developed the application in CF and I have been migrating to IIS as changes and improvements are made. Sitting down and rewriting in .NET would take me 12 months...
just not a reality. Working around this problem is a real pain and I don't trust the .NET installation. I can't afford to have *ANY* downtime with this application as it is a major line of business application for a large oil company.