Error after re-ghosting a page layout

For a customer, we deployed a MOSS site in a multi-stage environment using solutions. That's the right way to do it but can be a pain when you upgrade to a newer version. In our case, we ran into a problem with page layouts that became un-ghosted. If you strictly work with solution upgrades and do not touch the page layouts with SharePoint Designer or upload new versions in the master page catalog, you should be OK. In our case, some page layouts became un-ghosted after custom changes by the customer. After a solution upgrade, our deployed changes were not visible. That is, unfortunately, by design behavior. I had to find a way to re-ghost the page layouts, but only the ones from our solution. I'll post the custom tool I build for this somewhere soon, but wanted to share something else first.

After re-ghosting the page layouts, I got an error message on pages based on some page layouts, but not others:

Value does not fall within the expected range.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ArgumentException: Value does not fall within the expected range.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[ArgumentException: Value does not fall within the expected range.] Microsoft.SharePoint.Library.SPRequestInternalClass.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSetupPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObjectIsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocId, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder) +0 Microsoft.SharePoint.Library.SPRequest.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSetupPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObjectIsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocId, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder) +215 Microsoft.SharePoint.SPWeb.GetWebPartPageContent(Uri pageUrl, PageView requestedView, HttpContext context, Boolean forRender, Boolean includeHidden, Boolean mainFileRequest, Boolean fetchDependencyInformation, Boolean& ghostedPage, Byte& verGhostedPage, String& siteRoot, Guid& siteId, Int64& bytes, Guid& docId, UInt32& docVersion, String& timeLastModified, Byte& level, Object& buildDependencySetData, UInt32& dependencyCount, Object& buildDependencies, SPWebPartCollectionInitialState& initialState, Object& oMultipleMeetingDoclibRootFolders, String& redirectUrl, Boolean& ObjectIsList, Guid& listId) +1553 Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.FetchWebPartPageInformationForInit(HttpContext context, SPWeb spweb, Boolean mainFileRequest, String path, Boolean impersonate, Boolean& fGhostedPage, Byte& verGhostedPage, Guid& docId, UInt32& docVersion, String& timeLastModified, SPFileLevel& spLevel, String& masterPageUrl, String& customMasterPageUrl, String& webUrl, String& siteUrl, Guid& siteId, Object& buildDependencySetData, SPWebPartCollectionInitialState& initialState, String& siteRoot, String& redirectUrl, Object& oMultipleMeetingDoclibRootFolders, Boolean& objectIsList, Guid& listId, Int64& bytes) +692 Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.FetchWebPartPageInformation(HttpContext context, String path, Boolean impersonate, Boolean& fGhostedPage, Byte& verGhostedPage, Guid& docId, UInt32& docVersion, String& timeLastModified, SPFileLevel& level, String& masterpageUrl, String& customMasterPageUrl, String& webUrl, String& siteUrl, Guid& siteId, Object& buildDependencySetData) +132 Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.GetWebPartPageData(HttpContext context, String path, Boolean throwIfFileNotFound) +773 Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.GetFile(String virtualPath, Boolean fetchContent) +78 Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.GetFile(String virtualPath) +29 Microsoft.SharePoint.ApplicationRuntime.SPVirtualPathProvider.GetFile(String virtualPath) +171 System.Web.Hosting.VirtualPathProvider.GetFile(String virtualPath) +18 System.Web.Hosting.VirtualPathProvider.GetFileWithCheck(String virtualPath) +11 System.Web.FormatterWithFileInfo.GetSourceFileLines(String fileName, Encoding encoding, String sourceCode, Int32 lineNumber) +229 System.Web.DynamicCompileErrorFormatter.get_MiscSectionContent() +926 System.Web.ErrorFormatter.GetHtmlErrorMessage(Boolean dontShowSensitiveInfo) +818 System.Web.HttpResponse.WriteErrorMessage(Exception e, Boolean dontShowSensitiveErrors) +645 System.Web.HttpResponse.ReportRuntimeError(Exception e, Boolean canThrow, Boolean localExecute) +271 System.Web.HttpRuntime.FinishRequest(HttpWorkerRequest wr, HttpContext context, Exception e) +338

 

It had to be related to my re-ghosting. I did a few checks to find out what went wrong:

• compare the page in the master page gallery with the one in Visual Studio (opened the file from the gallery in SharePoint Designer and saved to a local file on which I did a file diff). There were no differences.
  
• opened the page in SharePoint Designer and just saved. Now the page worked again!
  

I couldn't find anything on this error that made sense. Was the page instance somehow linked to an un-ghosted instance of the page layout? After some frustration, I decided to check the Event Viewer on the server for some more clues and saw the following:

Process name: w3wp.exe
Account name: [mythreadaccountname]

Exception information:
Exception type: HttpParseException
Exception message: http://server//_catalogs/masterpage/[mypagelayout].aspx(162): error CS0102: The type 'ASP.[mypagelayout]_ASPX__663741266' already contains a definition for 'datetimefield3'

Request information:
Request URL: [myurl].aspx
Request path: [mypath].aspx
User host address: [myipaddress]
User: [me]
Is authenticated: True
Authentication Type: NTLM
Thread account name: [mythreadaccountname]

Thread information:
Thread ID: 1
Thread account name: [mythreadaccountname]
Is impersonating: True
Stack trace: at System.Web.UI.TemplateParser.ProcessException(Exception ex)

at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)

at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)

at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath)

at System.Web.UI.TemplateParser.ParseInternal()

at System.Web.UI.TemplateParser.Parse()

at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType()

at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider)

at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders()

at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()

at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)

at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)

at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)

at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)

at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert)

at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)

at System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)

at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)

at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

 

Ah, that made more sense! When I looked in the aspx page, I verified there were two fields with the same ID! As the page is created in but not compiled by Visual Studio, we completely overlooked this. Now it started to make sense: when a file is ghosted, it is handled by the compiler on the server. In that case, mistakes like duplicate IDs will be punished. After fixing the duplicate ID problem and upgrading the solution, the problem was gone.

So why did my un-ghosted file not give any errors? Well, it's the way it's parsed that makes the difference. Un-ghosted files are retrieved from SQL server and handled by the safe mode parser, which seems to be less picky with sloppy coding. For some more info on ghosting and parsing, see http://www.megasolutions.net/Sharepoint/Sharepoint_Integration_with_Asp_net_2.aspx.