4

All the SharePoint applications I work on use resource files to allow localisation and sitemap files to integrate with breadcrumbs.

It has always been a problem to deploy and process these files as part of a standard WSP deployment as the recommended API call (ApplyApplicationContentToLocalServer) requires local administrator access for the owstimer service, which goes against best practices.

I know there are a number of ways around this in SharePoint 2007, which involve basically writing your own implementation of ApplyApplicationContentToLocalServer, but I had hoped that in SharePoint 2010 this obvious flaw would have been fixed.

Unfortunately the code still checks if the current user is local administrator (I used reflector on the SP2010 Microsoft.SharePoint.dll file)

if (!SPAdministrationServiceUtilities.IsCurrentUserMachineAdmin())
{
    throw new SecurityException(SPResource.GetString("AccessDenied", new object[0]));
}

So, to cut a long and very frustrating story short. Is there a new, built-in, way in SharePoint 2010 to deploy resource files to the App_GlobalResources folder and process sitemap files?

For a good breakdown of the problem see this excellent post by Sean McDonough.

Update: We have completely rewritten the deployment mechanism for sitemaps and resource files. We can now deploy everything to all machines in a farm for SP2007 as well as SP2010. Keep an eye on our blog as we hope to release the code in the near future.

Jeroen Ritmeijer
  • 4,897
  • 1
  • 23
  • 33

2 Answers2

3

Good news on one of those fronts at least - resources CAN now be easily deployed to the App_GlobalResources folder. One of the enhancements to the WSP framework is that it now has the capability to deploy files to this location, courtesy of a new XML element 'App_GlobalResourceFile'.

To use, simply mark your resource file as 'AppGlobalResource' for the DeploymentType property in Visual Studio, and this element will be created for it.

[Note that the 'resources' and 'wpresources' folders within the web application root can also be targeted (using DeploymentType = 'ApplicationResource' or 'DwpFile' respectively), but are considered legacy.]

Unfortunately, these are the only locations under the web application root (as opposed to the SharePoint root) that the WSP framework can target. Yeah I wish this wasn't the case too. So you'll have to use the same techniques as before for sitemap files, or indeed anything under the web app root which isn't a resource. Still, the improvements for resources are definitely welcomed by those creating localized solutions.

P.S. I talked about this and other enhancements to the Features and Solutions frameworks at the SharePoint Evolutions conference last week - I'll be posting the slide decks over the next couple of days if that's of interest.

Chris O'Brien - MVP
  • 3,655
  • 18
  • 14
  • Thanks Chris. Unfortunately, as we target both SP2010 and SP2007 with the same VS2008 project, we cannot use VS2010's SharePoint functionality. But then, I didn't make that clear in my question :-) – Jeroen Ritmeijer Apr 28 '10 at 12:55
  • If you have different Features (presumably you're outputting different WSPs), you could manually add 'App_GlobalResourceFile' into your Feature elements files though. Not sure if that helps. – Chris O'Brien - MVP Apr 28 '10 at 13:24
  • Manually? :-) I guess that is possible, but that would still leave the problems with the sitemap files so I am looking into writing custom code to sort it all out in one go. Should really have been included in the base product, but hey nothing is perfect. – Jeroen Ritmeijer Apr 28 '10 at 15:36
1

Dont know about the sitemap file, but read this blog post on how localization is done in VS2010

http://blogs.msdn.com/johnwpowell/archive/2009/11/29/sharepoint-2010-localization-with-visual-studio-2010.aspx

Anders Rask
  • 17,949
  • 3
  • 38
  • 71