SharePoint 2010: Error 7043 “Load control template file /_controltemplates/TaxonomyPicker.ascx failed”
You install Microsoft Sharepoint 2010 RTM on Windows 2008 R2, you receive the following error message multiple times in the application event log:
Event Type: Error
Event Source: SharePoint Foundation
Event Category: None
Event ID: 7043
Description: Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=188.8.131.52, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.
The ULS log is created in a code path where all control templates are loaded into the web application. This is a one time process which happens just before showing any UI to the user after an IISReset.
The source of the problem looks like a stale control template in the control templates folder while the control itself has been removed from the code base.
This is not causing any issues except for a wrong ULS log message a single time in a web application process life time, the exception is caught and that template file is skipped. This message should be treated as log noise and can be ignored.
To change this behavior:
- Navigate to /14/TEMPLATE/ControlTemplates/TaxonomyPicker.ascx user control
- Open the user control in a text editor and locate the first line
- Find the character string , and replace with a comma ‘,’ (without quotes).
- Save the user control
I have run into this issue myself. In my case I had the following scenario:
- Initially, my web application had ‘Browser File Handling’ set to ‘Strict’ (which is the default when creating a web application)
- Created a site collection, then a custom document library, and saved it as a template
- Created a new document library using the template
- Changed the web application ‘Browser File Handling’ to ‘Permissive’
- Found that I still was prompted to save PDF files before opening in the document libraries created with my template. Document libraries created with the out-of-the-box templates worked as expected.
I am sure there are more scenarios where this issue would surface, perhaps saving a web as a template before changing ‘Browser File Handling’. Although I should do more testing for a complete list of scenarios, I needed to find out what was the cause. So I investigated.
Each Document Library in SharePoint 2010 actually has a property titled BrowserFileHandling that is set based on the BrowserFileHandling selection at the Web Application level. In the scenario I described above, I have found that the inheritance of this property does not always behave as you would expect. Using PowerShell (you could also use the object model) you can take a look at the BrowserFileHandling property at the Document Library level as this is not exposed in the UI.
Here is some PowerShell to help and please note this is used in the SharePoint 2010 Management Shell
$web = Get-SPWeb “http://yourspweburl”
#Get Document Library
$docLib = $web.lists[“Your Document Library Title”]
#View all properties/methods of the Document Library and you’ll see that BrowserFileHandling is a property
$docLib | Get-Member
#See the current BrowserFileHandling setting for the Document Library
#If you need to change it from Strict to Permissive
$docLib.BrowserFileHandling = “Permissive”
Even if the template scenario that I describe isn’t your scenario you can certainly use the above PowerShell code to inspect, and if necessary, change the BrowserFileHandling property in a Document Library that is presenting the problem you describe.
Reference : Resources and Tools for IT Professionals | TechNet