The title pretty much says it.

My target is to deploy a custom alerttemplates.xml to my SharePoint 2010 solution programmatically. Which would decrease the steps for an installation of the solution, since this gets done automatically when the feature gets activated.

The only Problem, this doesn't work as it should be. That's what I've done: I've created a method to execute stsadm operations from within my code; the critical part is: (Note: Normally, the arguments(string) is created dynamically and is a parameter of the method; Not shown here for simplicity, but that's how it would look like.)

string prgFilePath = System.Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)
    + @"\common files\microsoft shared\web server extensions\14\bin\stsadm.exe";
string arguments =  "-o updatealerttemplates -url http://spserver/ "
    + @"-filename + C:\custom\alerttemplates.xml";
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.EnableRaisingEvents = false;
proc.StartInfo.FileName = prgFilePath;
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.Arguments = arguments;
worked = proc.Start();

When I use the SharePoint Management-Shell and do it manually "stsadm -o update[...]" this works just fine. But this doesn't seem to work, and I can't figure out why.

Did I forget something? Is this the wrong way to do it? (Call Powershell instead and call the stsadm.exe) I'm not quite sure what to do here since I rarely work with stsadm.exe/(Power)shell related stuff. I'm just the guy that uses Visual Studio. :)

Could it be an issue that the paths in the Verbatin-strings (@"") get translated and ultimately send to the stsadm.exe as "C:\custom\alerttemplates.xml"? (Normally that's no issue, I know. But maybe, maybe in this case it is?)

I'd really appreciate when someone could give me hint on that matter.

Also: What's with filepaths that have blank spaces? Just set " in front and at the end?

  • Do you get an error or an exception? If yes, what does it say?
    – Matthias
    Commented Oct 20, 2011 at 12:59
  • @Matthias Neither. The "worked" object is a bool, and the Start() Method returns true every time. I don't see the shell-window as well, so I have no visual confirmation. (I tried to set CreateNoWindow on false; didn't work) And of course I check the prgFilePath with File.Exists() too.) The only indication I have that something is running, is that when debugging the code, the line with the WaitForExit() method takes a few seconds to skip. (about the same time the stsadm command needs to perform, when I do this manually) Is there some way to log the lines the stsadm.exe prints? Commented Oct 20, 2011 at 13:14
  • Is there a reason you're using stsadm instead of calling directly into the SharePoint Object Model? Error handling is much harder when the work is done in another process.
    – bmm6o
    Commented Oct 20, 2011 at 16:06
  • @bmm6o, I wasn't aware of the fact that using the object model is an option, too. I'll check out your answer, it looks intriguing. :) Commented Oct 21, 2011 at 6:23

3 Answers 3


In general, I've found two superior alternatives to launching stsadm as a separate process. First is using the SharePoint Object Model. In your case, this would be with the function SPAlertTemplateCollection.InitAlertTemplatesFromFile. This gets you the best error handling story.

If there's something that's not exposed via the OM or it's more work than you want to spend, you can load the stsadm assembly and call directly into it. For instance:

Assembly stsAss = Assembly.LoadFile(StsadmPath);
Type stsAdmType = stsAss.GetType("Microsoft.SharePoint.StsAdmin.SPStsAdmin");
MethodInfo main = stsAdmType.GetMethod("Main");
main.Invoke(null, new Object[] { new String[] { "-o", "updatealerttemplates" } }); // add other parameters to end of the string array

Both of these require that your program is running x64 and with admin priviliges.

  • thanks man, it works like a charm. The tip with the InitAlertTemplatesFromFile() method is worth gold! I realized it this way in one neat line: new SPAlertTemplateCollection((SPWebService)SPWebApplication.Lookup(new Uri(SPContext.Current.Site.Url)).Parent).InitAlertTemplatesFromFile(@"path\alerttemplates.xml"); Commented Oct 21, 2011 at 8:50

I've been successful with the following script

Process exportSite = new Process();

string commonFilesPath = System.Environment.GetFolderPath(System.Environment.SpecialFolder.CommonProgramFiles);
string commandLine = " -o export -url " + SPContext.Current.Web.Url + " -filename c:\\" + tempName + ".exp -overwrite -includeusersecurity";

exportSite.StartInfo.UseShellExecute = true;
exportSite.StartInfo.FileName = commonFilesPath + @"\Microsoft Shared\web server extensions\12\BIN\" + "stsadm.exe ";
exportSite.StartInfo.Arguments = commandLine;
exportSite.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;



I think the problem is with your arguments:

string arguments =  "-o updatealerttemplates -url http://spserver/ "
    + @"-filename C:\custom\alerttemplates.xml";

Remove the +.

For filepaths with spaces in your arguments, you can escape them using \". For example:

string arguments =  "-o updatealerttemplates -url http://spserver/ -filename \"C:\\custom\\my alert templates.xml\"";
  • normally there's no plus; (And I highly doubt that would be a problem) I only did it here so it looks cleaner. Also thanks for the info with the " in front and at the end. But when using " in Verbatim-strings \" wouldn't work, instead using "" is the right way. Commented Oct 20, 2011 at 15:12
  • Woops, you're right. I updated the string to not use @ strings. I'm still not convinced about the "+" you have in there.. unless it was a copy paste error?
    – Kit Menke
    Commented Oct 20, 2011 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.