Original: 2009/5/6
Updated: 2009/12/1 – see bottom
Updated: 2009/12/31 – see bottom (Follow up post here)
Have you ever had a need to deploy some files to all of the virtual directories (every IIS site folder corresponding to a zone in the web app) for a SharePoint web application feature? After searching the interwebs high and low I was unable to find any information relating to this topic, so this might very well be one of the first publicly available. I want to say that getting this to work yesterday was one of the most fun development tasks I’ve done in awhile. Hopefully this can help someone else who is struggling with the same task or at least give you some fun things to try out.
First the premise. My client is hosting Reporting Services 2005 reports for a SharePoint custom application. The custom application lives in the Layouts folder of the 12 Hive. The reports will not be hosted on Reporting Services, but instead locally in the web application. Since the ReportViewer web control that will be displaying the reports only knows the virtual directory root (c:inetpubwwwrootwssVirtualDirectories<port number of SharePoint zone>) we need a way to copy the files into that directory (and all other virtual directories for the web app meaning 3 zones in our environment) instead of residing in the 12 Hive. As such we wanted a clean solution for deploying these reports to the virtual directory folder that had the least amount of human intervention (ex. a batch command that ran XCOPY to copy the files into hardcoded folders would require human intervention beyond deploying the WSP file).
As with all SharePoint development solutions, I (under the pain of death) recommend wrapping them up as features and files inside of a WSP file. I don’t recommend building your WSP by hand as it is very tedious and there are some free tools that can help you immensely in this area. Currently I use either Visual Studio extensions for Windows SharePoint Services 1.2 (VSeWSS) or WSPBuilder. Each has it’s own set of pros and cons, but I’ll save that for another blog post. On this project we’re using WSPBuilder as the lead developer began using it and I’ve been grandfathered into it.
So we have a WSPBuilder project with all of our custom application files laid out in the appropriate folders. Our reports are placed into a subfolder of feature DeployCustomApplication. During installation of the WSP solution these files are copied to the corresponding 12 Hive folder. To get them from that location to the web app virtual directory we created a feature receiver. Feature receivers allow custom code to be called upon feature install, activate, deactivate, and uninstall. The process is carried out as follows:
- Get reference to target web application
- For Each loop to process each dictionary pair in the web application’s IISSettings property
- Delete report files if they already exist (1)
- Perform file copy from the 12 Hive location to the bin directory of the individual web site virtual directory folders
(1) = Delete report files first as they are subject to source control and will be marked read-only. The copy method is unable to overwrite a read-only file even with the OverWrite boolean flag set to true.
Here is a screenshot of the report files in the WSP project (pixelation on files done with Paint.Net, excellent free program I use all the time for image modifications similar to Photo Shop). For those with a super keen eye you might even be able to tell that I doctored the report file names as well, but that’ll be our little secret.
Below is a slightly modified version (removing application name, client code, variable names, and other extraneous items) of the feature receiver code. As an added bonus, you’ll also see in the AddHttpHandlerVerb() method how another teammate developed a process to modify the web.config file of each virtual directory to allow the ReportViewer web control. I wish I could claim that as well, but sadly it was done by the time I joined the team. Here is a link to the below code: download code here.
1: using System;
2: using System.Collections.Generic;
3: using System.Text;
4: using System.IO;
5: using System.Web.Hosting;
6: using Microsoft.SharePoint;
7: using Microsoft.SharePoint.Administration;
8: using Microsoft.SharePoint.Utilities;
9: using System.Web;
10: using System.Web.UI;
11: using System.Web.UI.WebControls;
12:
13: namespace CustomApplication
14: {
15: class CustomApplication : SPFeatureReceiver
16: {
17:
18: private SPWebApplication _webApp;
19: private String _Owner;
20:
21: public override void FeatureActivated(SPFeatureReceiverProperties properties)
22: {
23: try
24: {
25: // get references to target web application and feature definition
26: _webApp = (SPWebApplication)properties.Feature.Parent;
27: _Owner = properties.Feature.DefinitionId.ToString();
28:
29: DeployReportFiles();
30:
31: AddHttpHandlerVerb();
32: }
33: catch (Exception ex)
34: {
35: string message = "Error occurred while activating CustomApplication feature";
36: Logger.logException(ex, message, System.Diagnostics.EventLogEntryType.Error, "<GUID>");
37:
38: throw new SPException("Error during Activation. See event log for further details");
39: }
40: }
41:
42: public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
43: {
44: try
45: {
46: // get references to target web application
47: _webApp = (SPWebApplication)properties.Feature.Parent;
48:
49: RemoveReportFiles();
50: }
51: catch (Exception ex)
52: {
53: string message = "Error occurred while deactivating feature CustomApplication";
54: Logger.logException(ex, message, System.Diagnostics.EventLogEntryType.Error, "<GUID>");
55:
56: throw new SPException("Error during Feature Deactivation. See event log for further details");
57: }
58: }
59:
60: public override void FeatureInstalled(SPFeatureReceiverProperties properties)
61: {
62: }
63:
64: public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
65: {
66: }
67:
68: private void DeployReportFiles()
69: {
70: // first remove report files if they exist
71: RemoveReportFiles();
72:
73: // loop through each IisSettings dictionary pair (zones [dafault, intranet, internet, etc.] configured for web application)
74: foreach (KeyValuePair<SPUrlZone, SPIisSettings> pair in _webApp.IisSettings)
75: {
76: // copy report from 12 Hive location to the IisSettings zone virtual directory
77: File.Copy(SPUtility.GetGenericSetupPath(@"TEMPLATEFEATURESCustomApplicationReportsReport1.rdlc"), pair.Value.Path.FullName.ToString() + @"binReport1.rdlc", true);
78: File.Copy(SPUtility.GetGenericSetupPath(@"TEMPLATEFEATURESCustomApplicationReportsReport2.rdlc"), pair.Value.Path.FullName.ToString() + @"binReport2.rdlc", true);
79: }
80: }
81:
82: private void RemoveReportFiles()
83: {
84: // loop through each IisSettings dictionary pair (zones [dafault, intranet, internet, etc.] configured for web application)
85: foreach (KeyValuePair<SPUrlZone, SPIisSettings> pair in _webApp.IisSettings)
86: {
87: // if Report1 report exists, delete
88: if (File.Exists(pair.Value.Path.FullName.ToString() + @"binReport1.rdlc"))
89: File.Delete(pair.Value.Path.FullName.ToString() + @"binReport1.rdlc");
90:
91: // if Report2 report exists, delete
92: if (File.Exists(pair.Value.Path.FullName.ToString() + @"binReport2.rdlc"))
93: File.Delete(pair.Value.Path.FullName.ToString() + @"binReport2.rdlc");
94: }
95: }
96:
97: private void AddHttpHandlerVerb()
98: {
99: // get reference to web config modification object and set properties
100: SPWebConfigModification HttpHandlerMod = new SPWebConfigModification();
101: HttpHandlerMod.Owner = _Owner;
102: HttpHandlerMod.Path = "configuration/system.web/httpHandlers";
103: HttpHandlerMod.Name = "add verb HttpHandler ReportViewer";
104: HttpHandlerMod.Value = "<add verb="*" path="Reserved.ReportViewerWebControl.axd" type = "Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />";
105:
106: // if web configuration modification exists, remove
107: if (_webApp.WebConfigModifications.Contains(HttpHandlerMod))
108: {
109: _webApp.WebConfigModifications.Remove(HttpHandlerMod);
110: }
111:
112: // apply web configuration modificatoin
113: _webApp.WebConfigModifications.Add(HttpHandlerMod);
114: }
115: }
116: }
What I like about this solution is that it was developed in a short amount of time (hour or two to work out kinks), it is easily repeatable, and can be applied to other needs besides just Reporting Services reports. Please leave any feedback if you end up using this process, have suggestions to make it better, or have any other comments. Thanks and enjoy.
<Update1 – 2009/12/1>
After 6 months using the below method to deploy files to our development environments, it wasn’t until just recently that I noticed a fatal flaw in the below design: files are only deployed on the server from which the feature activate command is processed. In plain English, if you have 3 web front ends (WFEs) and you activate the feature on WFE1 then WFE1 will get the files, but WFE2 and WFE3 will not. The solution to this problem was suggested by my new good friend Sean McDonough: deploy using a SharePoint timer job. I’m working on ironing out some of the changes for this and will have a new post on the matter once that’s complete. Look for a link to that post from here soon.
</Update1>
<Update2 – 2009/12/31>
Here is the link to the follow up post I mentioned above: Click here. After doing a little research and trying out timer jobs I found that a timer job was not the best solution for my situation. Instead I opted for a method of looping through the web front ends and doing a file copy directly to the servers. That same mechanism can be wrapped around the logic in this post so that files are copied to all web application folders on each web front end. Read more about it in that follow up post.
</Update2>
-Frog Out
