Interestingly, he was able to upload the XML, Doc and PDF files properly without any issues but it was failing only when he was trying to upload Adobe Portfolio or Zip files. This was interesting as Adobe Portfolio files are again PDF files only! Why would SharePoint not like Portfolio or Zip files?

Reading further about Adobe Portfolio files, noticed that almost all these files are large in size ( > 10-15 MB each), this lead to the thought that it has to do with the file size of the file being uploaded and not the type. I created  a clean machine with SharePoint 2010 and installed the event handler for my document library. From the customer’s stack trace, I had seen that it was crashing at CheckIn method call. So enabled Check-in/Check-out on the document library.

Now when I tried uploading small documents (1-5 MB each), it worked perfectly as it should and the event handler executed and updated the item name. Then I increased the file size of my DOCX file and made it 19 MB, now I am getting the crash consistently. So with all the file types with size of more than 20 MB or so caused the issue.

Now the troubleshooting, as the customer was using ItemUpdated event handler and then again calling SPListItem.Update() method within this event handler, it was causing the clash when SPFile.CheckIn was being called by the user from SharePoint UI. Now as the ItemUpdated event handler is asynchronous and the clash is happening.

Now SharePoint 2010 gives us control over the post event handlers, if they should be asynchronous or synchronous. By default all post-event handlers (ending with –ed) are asynchronous. So went ahead and added the following line in ELEMENTS.XML file:

<Synchronization>Synchronous</Synchronization>

Retracted the solution and deployed back again. Now the test time. Uploaded a 30 MB Word document and it went through without any errors. Tested again with different file sizes and different file types and it is working smoothly now. Just to make sure that it is the event synchronization that is working here, I removed the Synchronization element from the ELEMENTS.XML and redeployed the solution and I am back with the error.

So effectively, Synchronization element saved the day in the end.

This http://msdn.microsoft.com/en-us/library/ff512765.aspx gives the Synchronization element details.

The article http://msdn.microsoft.com/en-us/library/ee536171.aspx gives the details of event handler improvements in SharePoint 2010.

Hope this helps in saving some of your time

-Manpreet

Recently got a customer who had created a BDC application definition file but when trying to import it, he is getting error:

The following error occurred: cannot have more than 255 Parameters for a method .Error was encountered at or just before Line: '1414' and Position '14'.

We checked and found that none of the methods had parameters north of 255. So this error was a little surprising.
Another simple BDC app definition file was imported successfully in same server.
Strangely, the AppDef file with error, was working on another SharePoint farm. In both the farms customer was at build 12.0.0.6421.

Now this is a surprise, same build number and same XML file and 1 farm would let it import and another would just refuse with a misleading error.

So the obvious place to start was to find the root of the error from belly of SharePoint. Started digging into SharePoint RTM version’s source code and found the limit to be 30 parameters per method. Checked and found all the methods in customer’s XML which are causing issue are having more than 30 parameters.

True, this was a limit in RTM build of SharePoint but still the error message says “255” parameters, which is still a mystery.

Checking the further source code and found that somewhere around Build 12.0.0.6331 the limit was updated to 255 parameters for a method.

So that explains the number “255” in error but still none of the methods giving error in customer’s XML file were having more than 255 parameters. It was in range of about 35 parameters for each method.

It was clear now that the issue is in binaries.

Then it was time to go back to customer and ask how SharePoint was installed and what was the patch sequence.

The answer: He installed SharePoint 2007 with SP2 Trial edition and then upgraded to enterprise license. Also he confirmed that all the machines where he installed using the same installer, he is facing the issue with this particular BDC AppDef file. So it does look like binary files issue. The production farm was installed with SharePoint 2007 SP1 Enterprise and then upgraded to SP2.

The resolution? Before we could troubleshoot further to find which binary is causing issue with SharePoint 2007 with SP2 Trial install, customer nuked the test server and rebuilt it again using the SharePoint 2007 SP1 Enterprise and upgraded to SP2 and issue was resolved !!

Happy troubleshooting…

   1: SPServiceContext context = SPServiceContext.GetContext(SPServiceApplicationProxyGroup.Default, SPSiteSubscriptionIdentifier.Default);

   2: SearchServiceApplicationProxy searchProxy = context.GetDefaultProxy(typeof(SearchServiceApplicationProxy)) as SearchServiceApplicationProxy;

   3: SearchServiceApplicationInfo ssai = searchProxy.GetSearchServiceApplicationInfo();

   4: SearchServiceApplication application = Microsoft.Office.Server.Search.Administration.SearchService.Service.SearchApplications.GetValue<SearchServiceApplication>(ssai.SearchServiceApplicationId);

   5: Schema sspSchema = new Schema(application);

   6:  

   7: ManagedPropertyCollection managedProperties = sspSchema.AllManagedProperties;

   8:  

   9: foreach (ManagedProperty managedProperty in managedProperties)

  10: {

  11:     string managedPropertyName = managedProperty.Name;

  12:  

  13:     //check to see if the managed property is mapped to one of our crawled properties

  14:     foreach (CrawledProperty crawledProperty in managedProperty.GetMappedCrawledProperties(managedProperty.GetMappings().Count))

  15:     {

  16:         if (!mappings.ContainsKey(crawledProperty.Name))

  17:         {

  18:             //if it is and has not yet been added to the list of managed fields, add it

  19:             mappings.Add(crawledProperty.Name, managedPropertyName);

  20:  

  21:         }

  22:     }

  23: }

Now when we hit the line 14 (ManagedProperty.GetMappings().Count), it always returns 0 (zero) as Mappings count. Now I am the Farm Administrator and the Service Account but still I am not able to pull in the data.

If I am logging into SharePoint Central Admin, I am able to see all the mappings from the SharePoint UI. So there must be something that SharePoint is doing which my custom application is not doing to get the data.

After searching on net for quite sometime and finding nothing, I started to dig into SharePoint’s source to see what is going on here and what is there behind the SharePoint’s UI, that makes it work.

Tracing the code and following its path, I figured out that you need to provide your account an Administrator access to Search Service Application.

Tried that and I added myself as Search Service Administrator under Central Administration Site -> Application Management -> Manage Service Applications -> Search Service Application and click on Administrators button in the ribbon and add myself to the list with Full Control. Once that was done, I was able to get the results properly without any issues.

But while adding myself to Search Service Application’s administrator, I noticed a line in the dialog box which said:

”Specify the users who have rights to manage this service application. These users will be given access to the Central Administration site and will be able to manage settings related to this service application. Members of the Farm Administrators group always have rights to manage all service applications.”

The line highlighted in RED, did not sound right. If I am already a Farm Administrator, I should have rights for this application. Then why I would need to add myself explicitly as Search Service Application administrator !!

This got me digging again and engaging my friendly escalation engineer onto it. After quite sometime studying the SharePoint’s code, a small line got our notice, which effectively said that (paraphrased):

If you are a Farm Administrator, you will have access to Search Service Application only from SharePoint’s Central Administration site. If you are not in Central Administration site, you would need to add yourself explicitly to the Search Service Application as administrator.

Basic message was, due to enhanced security in SharePoint 2010, you cannot execute this piece of code from a content web application (your team or publishing site) but ONLY from admin web application (aka SharePoint Central Administration website).

To validate this, I removed myself from Search Service Application’s administrator list. Now as my code was already there in _layouts folder, I accessed it using my Central Admin’s URL (http://sp2010a:2010/_layouts/testpage.aspx) instead of my application’s URL (http://sp2010a/_layouts/testpage.aspx) and IT WORKED !

So the root issue was visible now, that lead us to define our options in this case and we came up with the following 4 options for the customer:

1. Access the page using the Central Admin application's URL (may not be feasible due to security issues)
2. Add users as Search Service Administrators (again, may not be feasible due to security issues)
3. Add the app pool account of content application as Search Service Administrator and use SPSecurity.RunWithElevatedPrivileges to run the code in App Pool's context (this could work, but again can cause security concerns)
4. Host a web service on Central Admin site and access it from the Content application hosted layouts page (This would be the most preferred way to get it done)

Let me know if this helped you and which path did you choose.

Happy Coding…

-Manpreet

Customer is trying to use HTMLProp iFilter sample from the Platform SDK to index the fields as Date/Time but it is not indexing them as Date/Time but still being indexed as string only.

Why it happened?
By default, SharePoint's HTML ifilter (nlhtml.dll) converts all the meta field information from crawling to string type rather than their particular data type. After troubleshooting found, that the HTMLProp's implementation available in SDK may not be compatible with MOSS 2007 ifilter implementation.

HTMLProp is implementing IPersistFile but MOSS 2007 expects IPersistStream to be available, so it is not working with MOSS (got this information by using iFilter Explorer, a 3rd party tool)

How was it resolved?
Studied how nlhtml.dll works and modified the HTMLProp sample to use IPersistStream along with IPersistFile and registered it with MOSS. You can use the modified sample given along with the instructions from http://msdn.microsoft.com/en-us/library/dd582939(office.11).aspx to get it working.

To register the HTMLProp iFilter to work with MOSS, few registry entries need to be changed to make iFilter to load when indexing HTML and HTM files:

ADD your full dll path to following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex\DLLsToRegister

For the following 2 keys, need to change the (Default) value to "{f4309e80-a1db-11d1-a8fb-00e098006ed3}"-- This is GUID of our HTMLProp IFilter

Changed for MOSS
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.htm
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.html

Changed for WSS v3
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.htm

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.html

Important NOTE: Please make sure you take backup of registry keys before changing anything.

References:
IPersistFile - http://msdn.microsoft.com/en-us/library/ms687223(VS.85).aspx
IPersistStream - http://msdn.microsoft.com/en-us/library/ms690091(VS.85).aspx
http://blogs.msdn.com/ifilter/archive/2006/12/25/chronicles-of-an-ifilter-development-inception-to-deployment.aspx

HTMLProp_Updated_Sample.zip

We edited the DOCICON.xml file located at <drive>\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML to add a new entry for PDF in the <ByExtension> section:

<Mapping Key="pdf" Value="pdf.gif"  EditText="Adobe Acrobat" OpenControl="SharePoint.OpenDocuments"/>

After adding the above given entry and restarting the IIS, we got the entry in ECB menu to edit the PDF files but it was not opening the Adobe Acrobat product when clicked on it, but rather throwing a JavaScript error.

As customer also wanted some more control over how PDFs are being edited, we decided to go by the custom OpenDocuments control.

A custom OpenDocuments control was implemented using C# in an attempt to replicate the functionality provided by SharePoint.OpenDocuments control. But with time, it was created into a generic control, that try to find out the application associated with the given file extension, on the client machine and try to do a ShellExecute to open the file.

As the custom control is implemented as a COM control, you would need to register the control in the registry of the client machine. There are a couple of sample registry files in the attached zip archive, which can take care of registering and un-registering  of the control. The sample registry files assume that the control is in the GAC of the client machine.

On the SharePoint end, you would need to change DOCICON.xml file to tell SharePoint to use your custom control when clicked on your custom extension, by changing the <ByExtension> section entry to:

<Mapping Key="pdf" Value="pdf.gif"  EditText="Adobe Acrobat" OpenControl="Malag.OpenDocuments"/>

Notice that we have changed the “OpenControl” attribute of <Mapping> tag to point to our custom control.

The code for Malag.OpenDocuments control is attached. Hope this provides you with pointers to get you started on the path of created custom OpenDocuments control implementation.

Happy Coding…

Malag.OpenDocuments.zip

All the web.config entries were proper and also the website was working properly from web browser. After some troubleshooting, found that customer is having the web part assemblies in the BIN folder of the web application (under <drive>:\Inetpub\wwwroot\wss\VirtualDirectories\<port>\bin). They had a dependency on a 3rd party assembly which was not signed, therefore cannot put their assemblies in the GAC.

Now how does this translates to error from the custom timer job?

OWSTIMER is where the timer job is running, and when it accesses the WebPartManager, it tries to instantiate the web parts, and the web parts were deployed to the BIN directory of the web app. Since OWSTIMER is not a web application and does not know where is the BIN folder hosted so eventually doesn't have access to the web part and get this error.

You can read more about Assembly Placement at http://msdn.microsoft.com/en-us/library/2h3sywsc(VS.85).aspx.

So what was the solution in this case?

1. Deploy the web parts to the GAC. This will require strong naming the assemblies, which was not possible in this situation.
2. Copy the web part assemblies in question to the 12 directory. This will provide access to the web part assemblies to OWSTIMER. (Reference: Assembly Placement)

Hope this helps you save sometime while troubleshooting… as always… Happy Coding

If the application pool does not exist you can create it using the following code snippet:

   1:  SPFarm farm = SPFarm.Local; 

   2:  SPWebService service = farm.Services.GetValue<SPWebService>(); 

   3:  SPApplicationPool appPool = new SPApplicationPool("App Pool Title", service); 

   4:  appPool.CurrentIdentityType = IdentityType.SpecificUser; 

   5:  appPool.Username = "domain\\username"; 

   6:  appPool.Password = "password"; 

   7:  appPool.Update(); 

   8:  appPool.Deploy();

Be aware that application pools you created in IIS directly cannot be used with the SharePoint object model. The reason is that these are not known in the Config DB and they could also be with different configuration on different WFE's in the farm.

So you have to ensure that the application pool has been created using the method above. Once the application pool is created or it already exists you can look it up using the following code snippet and assign to the SharePoint application:

   1:  SPFarm farm = SPFarm.Local;

   2:  SPWebService service = farm.Services.GetValue<SPWebService>();

   3:  SPApplicationPool appPool = service.ApplicationPools["App Pool Title"];

   4:  

   5:  SPSite site = new SPSite("http://url-to-your-sitecollection");

   6:  SPWebApplication webApp = site.WebApplication;

   7:  webApp.ApplicationPool = appPool;

   8:  webApp.Update();

   9:  webApp.ProvisionGlobally();

Hope this helps you to elevate some issues… Happy Coding…

So what is causing the issue?
Digging into SharePoint, found that this is hard-coded and SharePoint will only show Incoming Email settings link for OOTB lists of type Announcements, Event, Document Library, Picture Library, XML Form, Discussion Board, Posts.

Then what is the solution?
If you create a custom list, you need to create a custom email event handler and attach to your list and then Incoming Email settings link will be available. But that would also mean you miss out on the default settings like security, save original email etc. which are provided by OOTB incoming email settings page. With custom list, you are able to set just that whether list is allowed to received email and if yes, what is the alias.

If you are creating your own email event handler and attaching to a list, you would need to handle everything else yourself like email attachments, save the original email, security etc. which is by-default handled by SharePoint otherwise.

Here is a sample code for an Email event handler which you can use as a building block:

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Text;

   4:  using System.IO;

   5:  using Microsoft.SharePoint;

   6:  using Microsoft.SharePoint.Utilities;

   7:   

   8:  namespace SimpleEmailHandler

   9:  {

  10:      public class EmailHandler : SPEmailEventReceiver

  11:      {

  12:          public override void EmailReceived(SPList list, Microsoft.SharePoint.Utilities.SPEmailMessage emailMessage, string receiverData)

  13:          {

  14:              base.EmailReceived(list, emailMessage, receiverData);

  15:   

  16:              // Add the whole email to the document library as .eml file

  17:              SPFile mFile = list.RootFolder.Files.Add(DateTime.Now.ToLongDateString() + "--" + DateTime.Now.ToLongTimeString().Replace(":", "-") + ".eml", emailMessage.GetMessageStream());

  18:   

  19:              // Get the SPListItem from the file just added

  20:              SPListItem item = mFile.Item;

  21:   

  22:              // Update the title, from and subject fields

  23:              // Make sure your list have got From and Subject fields in it

  24:              item["Title"] = "Recvd:" + DateTime.Now.ToString();

  25:              item["From"] = emailMessage.Headers["From"];

  26:              item["Subject"] = emailMessage.Headers["Subject"];

  27:   

  28:              // Update the item so that change made above are saved

  29:              item.Update();

  30:   

  31:              // Now we will add the attachments in the email to the document library

  32:              foreach (SPEmailAttachment attachment in emailMessage.Attachments)

  33:              {

  34:                  byte[] attachmentArray = new byte[attachment.ContentStream.Length];

  35:                  attachment.ContentStream.Read(attachmentArray, 0, (int)attachment.ContentStream.Length);

  36:                  list.RootFolder.Files.Add(DateTime.Now.ToLongTimeString().Replace(":", "-").Replace("/", "-") + "--" + attachment.FileName, attachmentArray);

  37:              }

  38:   

  39:              // Send an EventLog entry saying that we are done with the email processing...

  40:              System.Diagnostics.EventLog.WriteEntry("SimpleEmailEventHandler", "Simple Email event handler called...");

  41:          }

  42:      }

  43:  }

As always… Happy Coding

Basically they are pulling in the items from User Information list from SharePoint and adding them to a drop down in InfoPath form, from where the user selects the user and the final item is added to their custom list.

But why filtering is not happening? When checking their list, found that they have used “Single line of text” as their field type to store the username !!

SharePoint does not know how to compare or validate a user inside a “Single line of text” field, so it just ignores the formula given in the View and displays all the records.

Now a very visible thing looks like we need to change the field type from “Single line of text” to “Person or Group” type which will allow filtering of data on [Me] filter. But on other hand, InfoPath does not know how to handle the “Person or Group” type field, so it is still sending out the plain text.

Then it was ascertained that we need an event handler which will sit in-between and capture each item being added. That event handler will pull in the username from the item being submitted and convert it to the SPUser format that “Person or Group” field understand.

So the code was written to get the data from InfoPath form and create a “Person or Group” field value from there on.

   1: public override void ItemAdded(SPItemEventProperties properties)

   2: {

   3:     using (SPSite site = new SPSite("http://myMOSSsite/"))

   4:     {

   5:         using (SPWeb web = site.OpenWeb())

   6:         {

   7:             SPList list = web.Lists[properties.ListId];

   8:             SPListItem item = list.Items[properties.ListItem.UniqueId];

   9:             string assignedTo = properties.ListItem["Assigned To"].ToString();

  10:             SPPrincipalInfo userInfo = SPUtility.ResolvePrincipal(web, assignedTo, SPPrincipalType.All, SPPrincipalSource.All, null, false);

  11:             SPFieldUserValue userValue = new SPFieldUserValue(web, userInfo.PrincipalId, userInfo.DisplayName);

  12:             item["Assigned"] = userValue;

  13:             item.Update();

  14:         }

  15:     }

  16: }

Happy Coding and have fun…

But what happened? They lost the alert settings that everyone had for themselves over those hundreds of lists in the site and their sub-sites !! That too it was noticed after a day or so when some content has already been changed in the the sites.

I pointed him directly to the Technet article which tells about the issues that could happen with STSADM export and import and what is not saved. But he never read it and moved everything.

Now they wanted the alerts back but do not want to do their last days work again, which rules out a restore option from a day old backup. Finally, we settled that we will restore backup to a different sub-site in a farm and then write the code to copy over the alert information to the new site.

But where is the code?? Well, it is given below !!  Just provide 2 SPWeb objects, giving the source and destination and it will copy over your alert information.

   1: public void Copy(SPWeb sourceWeb, SPWeb destinationWeb)

   2: {

   3:     SPAlertCollection alerts = sourceWeb.Alerts;

   4:     foreach (SPAlert alert in alerts)

   5:     {

   6:         SPList list = destinationWeb.Lists[alert.List.Title];

   7:         Guid guid = destinationWeb.Alerts.Add(list, alert.EventType,

   8:         alert.AlertFrequency);

   9:         SPAlert newAlert = destinationWeb.Alerts[guid];

  10:         SPAlertTemplate template = new SPAlertTemplate();

  11:         template = alert.AlertTemplate;

  12:         template.Name = alert.AlertTemplate.Name;

  13:         newAlert.AlertTemplate = template;

  14:         newAlert.AlwaysNotify = alert.AlwaysNotify;

  15:         newAlert.DynamicRecipient = alert.DynamicRecipient;

  16:         newAlert.EventTypeBitmask = alert.EventTypeBitmask;

  17:         newAlert.Filter = alert.Filter;

  18:         newAlert.Title = alert.Title;

  19:         newAlert.Status = alert.Status;

  20:         newAlert.User = alert.User;

  21:         newAlert.Update();

  22:     }

  23: }

As always, Happy Coding