Timer jobs are wonderfully robust creatures. They effectively replace the "Windows Scheduled Task" for SharePoint servers, allowing you to run .Net code on a scheduled or "one off" basis.
However, there can be some confusion about running Timer Jobs on multiple servers, so this should clear it up a bit.
It is possible to run a Timer Job on every server on the farm (although this can be dangerous!)
The crux of all this is based on the SPJobDefinition constructor (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spjobdefinition.spjobdefinition.aspx).
The constructor includes a parameter for an SPServer object, which allows you to specify which server the timer job will run on.
Example Code 1 – Add Job to single Server:
The code below is for a Web Application scoped which will register a job definition on a single server. As Web Application scoped features are activated from Central Administration, it will use the current SPServer (i.e. the Central Admin server).
This is useful for code which modified content in the database, as you only want it to execute a single time.
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;
SPJobDefinition job = new SPJobDefinition("CustomJobDef", webApp);
}
Example Code 2 – Add Job to All Servers:
The code below is for a Web Application scoped which will register a job definition on all web front end servers in the farm.
This is useful for code which modifies files or server settings, as you need it to execute separately for each server.
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;
foreach (SPServer server in SPFarm.Local.Servers)
{
if (server.Role == SPServerRole.WebFrontEnd)
{
SPJobDefinition job = new SPJobDefinition("CustomJobDef", webApp, server, SPJobLockType.None);
}
}
}
Hope this helps! Enjoy!
public static void SetTargeting(SPList list, bool enabled)
{
if (list == null)
throw new SPException("List was not found.");
SPField targetingField = GetTargetingField(list);
if (enabled && (targetingField == null))
{
string createFieldAsXml = CreateFieldAsXml();
list.Fields.AddFieldAsXml(createFieldAsXml);
list.Update();
}
else if (!enabled && (targetingField != null))
{
// make sure the field can be deleted!
targetingField.AllowDeletion = true;
targetingField.Sealed = false;
targetingField.Update();list.Fields.Delete(targetingField.InternalName);
list.Update();
}
}
The message I really want to get across ... Don’t use Properties/Resources.resx
SharePoint resource files should be stored in one of 2 places (there are other places, but they are not commonly used):
· 12
o Config
§ Resources ß Location 1 – use this for all Pages, Controls and Web Parts
o Resources ß Location 2 – use this for all Features, Site Definitions, List Definition, Content Types (i.e. all CAML)
If you need to access those resources from code, then use the following:
C# (programmatically)
String strValue = System.Web.HttpContext.GetGlobalResourceObject(“NameOfResourceFile”, “NameOfProperty”).ToString();
ASPX Markup
<%$Resources: NameOfResourceFile, NameOfProperty%>
XML (CAML)
$Resources: NameOfResourceFile, NameOfProperty;
This effectively gives your virtual machine it's own private access to the corporate network .. great for those TFS check-ins and server builds :)
*sigh* another one for midnight oil.