MOSS: Event Log error when you have Ajax User Controls in Control Templates
I was recently working with Ajax controls in SharePoint. I created some ascx user controls and added them to the ControlTemplates folder of the 12 hive. I then dynamically loaded these controls to my web parts and everything worked fine. We did the deployment on the production server and the functionality worked very well.
After deployment we suddenly started facing some performance issues. These were sporadic and inconsistent but happened after a fixed amount of time. As part of troubleshooting we analyzed the event logs and found the error logged as:
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Web Controls
Event ID: 7043
Time: 1:31:45 PM
Load control template file /_controltemplates/xxx.ascx failed: Unknown server tag 'asp:UpdatePanel'.
I googled this error and found that this happens if you had not added the ajax settings properly. We checked the web parts where ajax controls were there but they worked perfectly fine. In fact we recieved no complaints from our end users for any failure of this functionality.
After a lot head banging, I checked the ULS logs and found this error:
04/01/2010 10:27:56.59 owstimer.exe (0x0BEC) 0x1E60 Windows SharePoint Services Web Controls 7043 Critical Load control template file /_controltemplates/xxx.ascx failed: Unknown server tag 'asp:UpdatePanel'.
Clearly the problem was in the owstimer service. And now I remembered that owstimer tends to load all the user controls (OOB and custom) in the controltemplates directory.
During our setting the environment of SharePoint to host ajax controls we add a asp tag in the web.config of the application for helping the pages in the web application to understand the tag prefix settings of the ajax dll.
But we dont do the same for owstimer service. huhhh…
So for solutions we can either:
1. Add the asp tag setting in the config of the owstimer.
2. Or, add the prefix in the user control itself.
I went with option 2 and it resolved the issue.