In a country where English is not the native tongue, localisation can be pretty important. Localisation within SharePoint is achieved by using resources and resource files. Although the use of resources is not mandatory, it’s usually good practise to use them anyway. You don’t want to hard code strings in your application, and, moreover, you never know when your application should be localized. Setting up and using these resources in SharePoint can be quite confusing. So here is a little article covering this topic.

Resources

Resources - in this case: strings - are contained within XML based .resx files. Every resource in such a file is identified by a fixed name. (quite like a HashTable) Here is a little example.

<root>
<data name="FieldManagerPageDescription">
<value>Manage the field of this application.</value>
</data>
</root>

For every new localization, you need a new .resx file with the same names as keys. You can just copy the original .resx file to achieve this quickly. In this new resource file you translate the original values within the value tag. The new resource file has to be named as follows: <original_name>.<culture>.resx.
eg. - myresource.resx
- myresource.en-US.resx
- myresource.fr-FR.resx

SharePoint & Resources

First thing you need to know, SharePoint defines two kinds of Resource files: Application resources and Provisioning resources. Application resources are resources used within the normal execution of the SharePoint application. Normal SharePoint execution include: Application Pages, Web Parts and Controls. SharePoint also makes a difference between application resources used in normal web applications and application resources used in the central administration. Don’t forget that. Provisioning resources, on the other hand, are used when provisioning elements, so you have to use them within features, site definitions and list definitions. Ok, now let’s see the practical side of it: deployment and usage.

1. Deployment

Resource files in SharePoint are located in different folders. Here is a list:

• C:\Inetpub\wwwroot\wss\VirtualDirectories\<port>\App_GlobalResources\
• <hive>\12\Resources\
• <hive>\12\CONFIG\Resources\
• <hive>\12\CONFIG\AdminResources\
• <hive>\12\TEMPLATE\FEATURES\<feature>\Resources\

So, how do you know where to put your resource files? Well, every type of resource has its own folders.

Provisioning resources

• <hive>\12\TEMPLATE\FEATURES\<feature>\Resources\Resources.<culture>.resx
• <hive>\12\TEMPLATE\FEATURES\<feature>\Resources\
• <hive>\12\Resources\

Every feature uses the resources file located in its Resources folder. You can however use another resource file or even share resources. To share resource files you have to put them in the 12\Resources\ folder. Site definitions and list definitions also get their resources from this folder.

Application resources

• <hive>\12\CONFIG\Resources\
• C:\Inetpub\wwwroot\wss\VirtualDirectories\<port>\App_GlobalResources\

Application resources are located in CONFIG\Resources folder. For a web application to use those resources, they have to be copied to their App_GlobalResources folder. (each web application has its own Global Resources folder) How is this done? At creation of the web application, the resources are initially copied to the App_GlobalResources folder. When adding new resources to the CONFIG\Resources folder, the resources have to be copied to existing web applications. You can do this manually or use the STSADM command: copyappbincontent.

Application resources: admin

• <hive>\12\CONFIG\AdminResources\
• C:\Inetpub\wwwroot\wss\VirtualDirectories\<port>\App_GlobalResources\

Application resources for the central administration work the same way as normal application resources, except that the base folder is CONFIG\AdminResources.

2. Usage

This last part will focus on how to use resources within SharePoint elements. Luckily it doesn’t really matter which kind of resource you are using. Here are the different ways:

In C#:
HttpContext.GetGlobalResourceObject("MyResource", "MyName").ToString();

In ASPX properties:
<%$Resources:MyResource, MyName%>

In ASPX as text:
<asp:literal runat="server" Text="<%$Resources:MyResource, MyName%>" />

In XML:
$Resources:MyResource, MyName

In XML features, using the default resource file:
$Resources:MyName

3. Conclusion

There you go. Everything you will ever want to know about resources in SharePoint.

Part of this article is derived from the excellent article of Mikhail Dikov. You can consider this article as some sort of extension of his article. Be sure to read it. Also, I’d like to thank Tom Verhelst for the heads up on the copyappbincontent. Thanks man!

Have a great week!

Dependency is one of those magic paradigms in Workflow Foundation which gives the use of the framework so much more richness, especially when using activities to break up functionality.
Dependency lets properties depend on other properties, and this in a dynamic way. In practise, if property object1.Property1 is dependent of object2.Property2 when you assign or get the Property1 of object1, you are actually modifying and retrieving Property2 of object2. The great advantage of this method and way of thinking is the avoidance of duplication of data. Also you enable activities to connect to each other.

So how does it work? There are actually two steps. The first one is the setup of the activity and its properties. The second one is the actual binding between two properties.

STEP 1 : Setup of the activity
Dependency at its core consists of two main classes: DependencyObject and DependencyProperty. The DependencyObject is the object that needs the data. It will do this by exposing properties which use DependencyProperty objects. One thing to remember is that when using dependency, the source object (the object which has the actual data) will never know that another object of objects is depending on it.
As dependency is one of the core paradigms of Workflow Foundation, it won’t come you as a shock to know that the base Activity class inherits from the DependencyObject class. The DependencyObject class exposes a number of methods to work with DependencyProperty’s. DependencyProperty’s are static values defined in the DependencyObject implementations. Those implementations (eg. Activities or Object1) are using these static values in Properties like this:

public class Object1
{
public static DependencyProperty Property1Property =
DependencyProperty.Register("Property1", typeof(string), typeof(Object1));

public string Property1
{
get { return (string)base.GetValue(Property1Property); }
set { base.SetValue(Property1Property, value); }
}
}

It is doing this as Properties should enhold actual data or link to other properties. This is why Workflow Foundation needed this alternative method with static values and internal methods. DependencyProperty’s define when a binding is chosen or when actual data is set. Actual data will be saved in an internal dictionary.

STEP 2 : Binding of properties
So how can we use these properties? There are two methods and both of them can be achieved in the visual designer as well as in code. (As you all know the visual designer is just creating code in the code behind designer class)
The first method is to use actual data. You can do this by assigning data to the property and retrieving them from the property, just like any other property. Nothing really special, actually.
The second and most interesting method is working with bindings. A new class is used to define them: the ActivityBind.

ActivityBind activityBind = new ActivityBind();
activityBind.Name = "object2";
activityBind.Path = "Property2";
this.object1.SetBinding(Object1.Property1, activitybind1);

As you see, the ActivityBind object creates a link to the object2’s Property2 property. As we are using this reference, the object2 does not actually know it is relied on by another object. Pretty simple.

In the end, it’s actually enough to remember just this one thing: if property object1.Property1 is dependent of object2.Property2 when you assign or get the Property1 of object1, you are actually modifying and retrieving Property2 of object2. Just keep to it, and you’ll be just fine. To end, here’s a quick overview. See ya.

object1..................object2
= DependencyObject.......= Plain object
= Target.................= Source
- Property1..............- Property2
...- get...=============>...- get
...- set...=============>...- set