Nick Grattan’s SharePoint Blog

About Microsoft SharePoint and some .NET

Archive for the ‘SharePoint General’ Category

SharePoint Global Resource (resx) file locations

with one comment

Global resource (resx) files are stored in the following locations in SharePoint 2010:

  • App_GlobalResources folder in the VirtualDirectories folder in inetpub (e.g. C:\inetpub\wwwroot\wss\VirtualDirectories\80)
  • Resources folder in the 14 hive (e.g. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources)
  • Config/Resources folder in the 14 hive (e.g. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\Resources)

In general, a single resx file in your solution should be copied into each of these locations during installation.  This is how they are used:

  • Resources files in App_GlobalResources are used when code in an ASPX page refers to a resource, e.g.

<asp:Label ID="lblNumberingTitle" runat="server" Text="<%$Resources:GlobalSiteResources, AutoNameTitle %>" />

  • Resources files in the Resources folder are used when referencing resources using the SharePoint object model, e.g.

btnExport.Text = SPUtility.GetLocalizedString("$Resources:GlobalSiteResources, Tab_Export", "GloablSiteResources", language);

  • Resources files in the Config/Resources are copied into the App_GlobalResources folder whenever a new web application is created. By adding the resx files here you will ensure your application will be able to access its global resource files in new web applications.

Written by Nick Grattan

May 24, 2011 at 12:53 pm

Opening SharePoint documents for Edit from Client Applications

with 7 comments

The ActiveX component “SharePoint.OpenDocuments” is used to open SharePoint documents ready for editing. It is documented here and is usually called from JScript code in a web page. But what about if you want to open a SharePoint document from a client application, such as a .NET WinForm or WPF application?

You might try the following code using the full URL to the document:

System.Diagnostics.Process.Start(docUrl); 

This will open the document in the client application (e.g. Microsoft Word), but it will always be opened read-only.

The following code will create an version specific instance of SharePoint.OpenDocuments and then call the EditDocument method to open the document:

        public static void OpenDocumentForEdit(string docUrl)
        {
            Type t = null;
             // get the correct version specific version...
            t = Type.GetTypeFromProgID("SharePoint.OpenDocuments.1");
            if (t == null)
                t = Type.GetTypeFromProgID("SharePoint.OpenDocuments.2");
            if (t == null)
                t = Type.GetTypeFromProgID("SharePoint.OpenDocuments.3");

            if (t == null)
            {
                System.Diagnostics.Process.Start(docUrl);    // best we can do, will open read-only
                return;
            }
            Object o = Activator.CreateInstance(t);
            object[] openParms = { docUrl, string.Empty };
            t.InvokeMember("EditDocument",
                System.Reflection.BindingFlags.InvokeMethod | System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Instance,
                null, o, openParms);
        }

Note that different versions of Office install different versions, and this code attempts to open the version installed on the client application. If none could be found it opens the document, albeit in read-only mode. When the method is called the following dialog will be presented to the user:

Written by Nick Grattan

December 31, 2010 at 7:29 pm

Will My MOSS Farm Stop Working?

with one comment

Or am I more likely to be abducted by aliens? Well, if you installed MOSS Service Pack 2 from a download before the 29th July 2009 your production MOSS Farm could stop working in the future. This is explained in Microsoft KB 971620 and in this Microsoft blog post.

In summary, initial releases of SP2 was configured as a trial version, and unless re-installed, MOSS features will stop working 180 days after you installed SP2. The value “180″ is reported in the KB, but this value seems to be different in practice.

To determine if your MOSS Farm is at risk you can:

  • Run Central Administration.
  • Select Operations.
  • Select Convert license type in the “Upgrade and Migration” section.

The description of “Current License” will show if you installed SP2 with the trial version problem:

sp2.PNG

You can also determine when the trial version will expire:

  • Run Central Administration
  • Select Application Management.
  • Select Check services enabled in this farm in the “Office SharePoint Server Shared Services” section.

A warning will be displayed if you’re running the trial version:

sp22.PNG

KB 971620 contains a link to a hotfix to correct this issue. This hotfix may require you to reboot the server. Before testing if the fix was applied correctly, issue an IISRESET before running Central Administration.

Thanks to Tim at Cork County Council for pointing out this issue.

Written by Nick Grattan

November 6, 2009 at 8:42 am

SharePoint Versions – MOSS v. SharePoint Services

with 2 comments

In this post I explained how to determine if your SharePoint installation is service packed, and to what level. However, the situation is a little more complex since your MOSS 2007 farm will be running Microsoft SharePoint Services 3.0 and MOSS on top.

When using Central Administration / Operations / Servers In Farm to report the version number you’re seeing the Windows SharePoint Services 3.0 version number. This will be updated when you run the Windows SharePoint Services (WSS) service pack update.

So how do you find which service pack for MOSS you’re running with? One way is to find the version number of the Microsoft.Office.Server assembly from the Windows GAC (Global Assembly Cache). To do this:

  • Run the Windows Explorer.
  • Navigate to \Windows\Assembly.
  • Right-click the file Microsoft.Office.Server and select Properties.
  • Click the Version tab.
  • Take a note of the “File Version”:

ver1.PNG

Here are the version numbers for the main MOSS services packs using this technique:

Service Pack

WSS Version (Central Admin)

MOSS Version from Microsoft.Office.Server
Unserviced packed 12.0.0.4518 12.0.4518.1014
Service Pack 1 12.0.0.6219 12.0.6211.1000
Service Pack 2 12.0.0.6421 12.0.6420.1000

Version numbers from the Microsoft.Office.Server assembly do not follow exactly those for the WSS reported version number, but there is a close correlation.

Written by Nick Grattan

November 5, 2009 at 7:47 pm

Where do customized site pages go

leave a comment »

Question: When a site page is customized where is it stored? Does it have to be copied to each web server in a server farm?

Answer: Site pages, such as “default.aspx” are stored in the appropriate folder for the site template under “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates”.

When these files are customised in SharePoint Designer the customized version of the file is stored in the content database in SQL Server for the site collection. Therefore the customized file is automatically available to all web servers.

Uncustomized site pages are shared between all sites that based on the site template. Sites that customize the site page have their own page that must be loaded from the content database, and are therefore less efficient.

In previous versions of SharePoint “customized” and “uncustomized” pages were known as “unghosted” and “ghosted”.

Written by Nick Grattan

August 22, 2007 at 8:02 am

Posted in SharePoint General

Follow

Get every new post delivered to your Inbox.

Join 50 other followers