Archive for the ‘SharePoint’ Category
Fixing Parser Errors in SharePoint
I have been getting the error below quite a lot in my SharePoint development environment, usually after updating a solution package.
The only fixes I was able to find by searching referred to mysteriously changed casing on placeholders, which was happening, but didn’t help in this case.
It turns out that this parser error actually has nothing to do with either parsing or the page being viewed. It can be triggered by just about anything – in this case it was an error finding the base class for a web part that was never on the page.
The actual error message can be found in the application event log – nothing useful gets added to the ULS logs.
Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: This page has encountered a critical error. Contact your system administrator if this problem persists.
Source Error:
Line 1:<%@ Page Inherits="Microsoft.SharePoint.Publishing.TemplateRedirectionPage,Microsoft.SharePoint.Publishing,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c" %> <%@ Reference VirtualPath="~TemplatePageUrl" %> <%@ Reference VirtualPath="~masterurl/custom.master" %><html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"><head>
Line 2: <!--[if gte mso 9]>-->
Line 3:<mso:CustomDocumentProperties>
|
Source File: /Pages/Home.aspx Line: 1
Developing with Multiple Versions of Visual Studio
One of the SharePoint projects I am working on involves a Visual Studio 2008 solution that is used across several teams of developers. I want to use Visual Studio 2010, but converting the projects would cause problems for anyone still using VS2008, and if everyone has to upgrade to VS2010 at the same time it will never happen.
Visual Studio does not support opening projects in multiple versions, and a search only came up with ways to maintain seperate projects, either manually or with some sort of sync process, which seems far too complicated.
Fortunately, it turns out that if the projects are simple enough, you can use them in both VS2008 and VS2010. It may not work for web apps or test projects, but for class libraries (or WSPBuilder solution projects) you just need to make a couple of manual edits to each project file.
- Remove the web app guid {349c5851-65df-11da-9384-00065b846f21} from ProjectTypeIds – this can be useful for adding WebForms designer support to WSPBuilder projects, but isn’t really necessary.
- Change the ToolsVersion attribute on project element to 4.0 – This tells VS2010 that it is the current version and does not require upgrade, while VS2008 will see the invalid version number and fall back to 3.5 with only a warning.
Once the project files are updated, simply create a new solution file for use in VS2010 and add the existing project files, which should now load without triggering the conversion wizard.
ASP.NET MVC Controller Actions in SharePoint
Having got Razor views working in SharePoint, I needed a better way to use them – displaying the view is three lines of fairly clean code, but it’s surrounded by the all the event handler methods you need in a web forms page or control.
It turns out that with the right code in the base class, a web part can look a lot like an ASP.NET MVC controller.
public class ExampleWebPart : MvcWebPart
{
protected override ActionResult Get()
{
var m = new DocSection()
{
Title = "Test Model"
};
return View(new DocView(), m);
}
}
The ActionResult/ViewResult classes have a similar interface to the ones in ASP.NET MVC, though they are quite simple so far. The key functionality is in the Execute() method, which actually renders the view. The standard ASP.NET ViewResult writes to the Response, but since this is happening inside a SharePoint page we need to add the content as a control on the page instead.
public override void Execute()
{
View.Model = Model;
View.Execute();
ParentControl.Controls.Add(new LiteralControl(View.Result));
}
Getting an ActionResult From the subclass and executing it happens in CreateChildControls – I’m not totally sure that is the best place for it, but it seems to be working well so far.
protected override void CreateChildControls()
{
if (!_error)
{
try
{
base.CreateChildControls();
var r = Get();
r.Execute();
}
catch (Exception ex)
{
HandleException(ex);
}
}
}
The full code can be found on github.
ASP.NET MVC 3 Razor Views in SharePoint
ASP.NET MVC 3 has just been released, and I really like the new Razor syntax for views. However, I work with SharePoint, which is solidly based on WebForms and .NET 3.5. Razor requires .NET 4, and while you can host WebForms MVC pages in _layouts, it’s an ugly hack that gives you the worst features of both systems.
Razor is internally quite different from WebForms, and the core functionality doesn’t actually require MVC, so it should be possible to use it in a system that can’t use MVC.
My first attempt to make Razor work under SharePoint was to see if it would compile without .NET 4. That didn’t work, but I did notice that most of the dependencies on .NET 4 are in parsing the templates – you can’t build cshtml files without .NET 4, but the generated code doesn’t require anything special.
Starting with the code from http://razorengine.codeplex.com/ I was able to convert a cshtml file into a cs file that can be compiled in a .NET 3.5 project. My version of the code is at https://github.com/tqc/RazorEngine.
RazorEngine came pretty close to what I needed, only requiring fairly minor changes:
- Add methods to return the generated source code rather than compiling and running it
- Copy the template base classes into a .NET 3.5 library (RazorEngine.Run). This meant removing support for dynamic objects, but apart from that the code doesn’t require the latest version.
I set up a console app (GenerateViewCode) that will generate code files for all cshtml files in a project. I considered using a single file generator, but a console app is easier to debug and more likely to work properly on a build server. It is intended to be set up as an external tool in Visual Studio:
- Command: GenerateViewCode.exe
- Arguments (base class for views): RazorEngine.Templating.TemplateBase
- Initial Directory: $(ProjectDir)
After you run the tool on a project containing cshtml files and include the generated code in the project, you will be able to render the view from your code:
var view = new TestViewLibrary.Views.Shared.DocView() view.Model = newTestViewLibrary.Models.DocSection(); view.Execute(); ParentControl.Controls.Add(new LiteralControl(View.Result));
This replaces either trying to build html in code (with code that looks a lot like the generated output from Razor) or finding and loading a usercontrol in _layouts.
MVC isn’t just about the view though – more on that shortly.
Gradual Upgrade, Large Databases and Timeouts
week has been migrating a system from SharePoint 2003 to SharePoint
2007 – like many things in SharePoint, this is something that is either
very easy or very hard.
The first challenge was getting prescan
to work. Prescan kept reporting that SharePoint 2003 SP2 was not
installed, even though it was. Turns out that as well as having SP2
installed you need to upgrade/extend all the web applications with that
version. It also doesn’t like the presence of non-SharePoint web
applications on the system.
The next issue was an exception in
ParseInt32 when checking the system version. It turned out to be simple
enough to fix, though I have no idea why the SystemVersion table
contained “6.0.2.6568*” instead of “6.0.2.6568″.
With prescan
finally running without errors, it was time for the actual migration.
The original plan was to just attach the database to a new 2007 server,
but that was not an option once we discovered that the database was
30GB larger than the hard drive on the new server – everything would
have to be done locally.
After installing 2007 on the 2003
server and selecting gradual upgrade, my first attempt at migration was
to attach the 2003 database to 2007 and do database migration with an
in place upgrade. This appeared to work quite nicely – the process
completed in about 20 minutes – until I tried to access the site. All
the data was copied, but nothing had a url and the site collections
list was empty.
With in place upgrade ruled out, it was back
to doing gradual upgrade of individual sites. All the references I
could find on doing this with large sites (the biggest single site
being 30GB) just said to use database migration instead.
Gradual
migration works by copying everything from the 2003 database into a
temp database, performing an in place upgrade on that, then copying
everything into the 2007 database. On small sites it’s great – All but
5 of the site collections were under 2GB and migrated without problems.
On larger sites it uses huge amounts of disk space (maybe 5 times the
database size), takes hours to run, and may timeout on some operations.
The
first timeout came when migrating a couple of 2GB site collections.
This one was in DropFullTextSearch. Reflector led me to
sp_fulltext_database and references to needing to reinstall windows.
Fortunately restarting the search service seemed to be enough – instead
of timing out after 30 minutes, the next run completed in 3 seconds.
Next
was the last site, the 30GB one. The timeout came in copying data to
the temp database. I found a technet post with instructions to pregrow
the temp database transaction log – it probably improved performance,
but not enough to stop the next run timing out as well. When copying
the Docs table, the upgrade process detects that it is full of 50MB
blobs and extends the timeout to a couple of days. When copying the
DocVersions table it doesn’t do this, and leaves the timeout at the
default 30 minutes. Although it’s possible a service pack fixes this, I
opted for the quick solution – removing all document versions.
To
do this I renamed the DocVersions table in the 2003 database with
sp_rename and recreated it – I could have deleted it, but this way it
can be restored quickly if necessary.
Without the versions,
migration completed successfully and as an added advantage the database
was down to 24GB, which should make things easier to get onto the new
server.
