I had an issue with some code that was deployed into a prod environment and threw an ‘object reference not set to an instance of an object’ error where it called the SPWeb’s AssociatedVisitorGroup. It turned out that our production environment didn’t have its visitor group setup yet. To do this go to the groups page (../_layouts/groups.aspx), and on the top of of the People and Groups view click on Settings and go to Set Up Groups. There you can create a new group or associate an already existing one.
I had some fun times debugging this issue today. There was an IIS virtual directory setup in the SharePoint web applications site with the same name as one of the variations in the site. In our example, we have a variations site for japan at http://www.patrickzaw.com/jp. There was a need to redirect a url (http://www.patrickzaw.com/jp/products) that didn’t exist within the Sharepoint site structure to another subsite that does exist (http://www.patrickzaw.com/jp/sites/productline). The solution put in place was virtual directory created in the same web application for /jp and then under that another one for /products which was setup as a redirection to the existing subsite.
Upon setting this up everything will work as expected until an app pool recylce, or IIS reset. When the app pool recycles the entire site will throw an unspecified exception.
It appears only to affect virtual directories with the same name as the variations site, but does not effect subsites with the same name.
Our resolution was to delete the virtual directories, restart IIS, and use SharePoint redirect pages instead. This did force us to create a subsite for /products that only had one redirect page. Please chime in if you have some better ideas of how to implement this.
The SmartPart Report can be downloaded at http://www.codeplex.com/SmartPartReport
If you use SmartParts then you’ll know how messy that usercontrols folder can get. Worse, if you’ve inherited a SharePoint project with many pages that has SmartParts used all over the site, most likely you’ll need to know where each user control is being used. This is the reason I came about making the SmartPart report.
The code is pretty straight forward. It basically loops through each file, looks for only aspx files, and then goes through each webpart and checks to see if the type is a SmartPart.
You could also expand upon this and search for other web part types as well. For example if you wanted to also look for Microsoft.SharePoint.WebPartPages.ListViewWebPart you can add it to the searchWebPartTypes array on line 83:
string[] searchWebPartTypes = { “SmartPart.SmartPart”, “SmartPart.AJAXSmartPart” , “Microsoft.SharePoint.WebPartPages.ListViewWebPart” };
It then uses reflection to get the “UserControl” property for a SmartPart. Again, if you’re using this to find another web part, you could put some conditions around this and modify the propertyname to get the value you’re looking for. Ex:
line 97:
string propertyName = “UserControl”;
string userControlFileName = “”;
if (webPartType == “Microsoft.SharePoint.WebPartPages.ListViewWebPart”)
{
propertyName = “Title”;
}
public SPListItemVersion GetLatestMajorVersion(SPListItem listItem)
{
SPListItemVersion latestMajorSourceFileVersion = null;
foreach (SPListItemVersion sourceListItemVersion in listItem.Versions)
{
Version thisVersion = new Version(sourceListItemVersion.VersionLabel);
if (thisVersion.Minor != 0)
{
continue;
}
else
{
if (latestMajorSourceFileVersion != null)
{
Version v = new Version(latestMajorSourceFileVersion.VersionLabel);
if (thisVersion.Major > v.Major)
{
latestMajorSourceFileVersion = sourceListItemVersion;
}
}
else
{
latestMajorSourceFileVersion = sourceListItemVersion;
}
}
}
return latestMajorSourceFileVersion;
}
Sharepoint Workflow Starter is a tool I made for helping with mass starting/stopping workflows for items accross a Sharepoint site.
Download: The executable and source code are available at http://www.codeplex.com/SPWorkflowStarter.
***TEST IN YOUR DEV ENVIRONMENTS FIRST!***
The app needs to be run on a Sharepoint server with an account that has sufficient permissions to access the API.
This is what it looks like…
So lets say you want to run the Approval workflow for every item in every list for a site and all its subsites. Here’s how we could do that:
1) Looking at the example above, you would first navigate to the site you want, in this case the root site http://stdemo.
2) Under that site we can find all the workflow templates available and we’ll select the Approval workflow template.
3) Once we select the Approval workflow template, you can check Run for all sub sites so that this workflow will run for all lists for this site and any sub sites.
4) You must choose the actions to take, stop, start, and you can also choose to use your own custom event data.
*Custom event data is the xml data passed to the workflow. When selecting a workflow template you will not see the event data that will be used by default because the workflow association to its list is what defines the event data. If you want to see what the event data looks like, select a list under that workflow template and you’ll see the event data used for that workflow association.
5) You can choose to log your results. This should always be done because I have yet to add any verbose output except in the logs.
6) Review your plan below and then click EXECUTE when ready.
The same steps above can be done for a list or single items in a list.
The tool still needs some work and if would like to help please drop me a line. Some future release features would be:
- Running workflows for multiple items (via checkbox)
- Better UI form design
- Better log output control
- Easier way to edit event data
- A lot of code clean up :-O
