Corey Roth [MVP]

At the ODC (where I should be this week), Microsoft announced version 1.1 of the Visual Studio 2005 extensions for Windows SharePoint Services.  This brings a lot of great new project templates and the ability to edit wsp files.  What is it lacking?  Well unfortunately Visaul Studio 2008 support.  I have already moved most of my SharePoint projects into Visual Studio 2008 and having no support for it is completely frustrating.  We're going to have to wait until June to see that support in version 2.0.

Another, thing that really disappoints me is that it still requires Windows Server and SharePoint to be installed just to install the extensions.  I use Virtual Machines to do development some, but I also do a lot of development from Windows XP and Vista and make use of Remote Debugging.  I understand the complexities of running things over the network, but can I at least install the project templates?  I am willing to deploy the files myself, it doesnt have to be automatic for me.

If you are still using Visual Studio 2005 on a Windows Server, then go ahead and install them because they will be pretty useful.  Here is the link.

 http://www.microsoft.com/downloads/details.aspx?FamilyID=3e1dcccd-1cca-433a-bb4d-97b96bf7ab63&displaylang=en

I ran into this one again lately when deploying.  We are folowing best practices with our connection strings by using Integrated Security.  We have several controls on the web site making use of SqlDataSource controls.  However, at runtime, we are left when an error like the following.

Microsoft.SharePoint.WebPartPages.DataSourceControlDisabledException: This control does not allow connection strings with the following keywords: ‘Integrated Security’, ‘Trusted_Connection’.

This is because SharePoint puts a tagMapping in the web.config that maps the ASP.NET SqlDataSource to its SPSqlDataSource.  Why it does this, I have no idea?  If I check the SDK on that class, there is not so much as even a description of what the class does (come on Microsoft, you still need to work on this SDK documentation).  A workaround is actually pretty simple, remove the tagMapping.  However, you can't just simply delete the line, you must use the remove element to get rid of it.

 <remove tagType="System.Web.UI.WebControls.SqlDataSource, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

This will allow the control to work, but you also need to register the ASP.NET SqlDataSource as a safe control.  You know the syntax, but here it is in case to make it easy.

<SafeControl Assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="SqlDataSource" Safe="True" AllowRemoteDesigner="False" />

That is all it takes and everything inside SharePoint still seems to work.  My point of today's post is to put out the following questions.

1. What is the purpose of this inherited control?
2. Why on earth would it not support integrated security?
3. Why does the SDK documentation continue to leave out details about key classes?

If you have the answer to any of those, please leave a comment.

In MOSS Enterprise Search, the maxium size of a file that it will index is 16 MB.  This is probably not an issue for most people, but some organizations do have large PDFs, PowerPoints, etc.  This is becoming a little more common knowledge, but I thought I would post it to make more people aware of it.  To change it, you need to add a DWORD at the following registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager

Add a new DWORD value of type Decimal called MaxDownloadSize.  The value should be in megabytes so a value of 50 would represent 50MB.  After you change this, you'll need to restart the Office SharePoint Server Search service and perform a full crawl.  Again, this is becoming more common knowledge, but I thought it was still worth mentioning.

I continue to work with LINQ to XML, and I thought this might be worth mentioning (although it is somewhat common sense).  An issue often when working with XML attribute (or elements) is that they might not always exists (i.e.: they are null).  Therefore, you need to check for this.  Specifically, this is an issue when you are assigning attributes into a new anonymous type (although it could occur using a regular type as well).  Consider the following example.  What if MyColumn is not present in some of the Item elements in the XML document?  The code would end up throwing an exception when you tried to enumerate items.

{

   MyColumn = item.Attribute("MyColumn").Value

How do you fix it?  First you use the Any() method of the attribute to see if any of that attribute exist.  Then it is just a matter of using shorthand if/then syntax.  Just replace MyColumn with the code below.

As you can see it is relatively simple, once you know to use Any() to look for the existance of an attribute. On a related note you can apply the same techique to see if an element exists.

I was working on an ItemEventReceiver the other day and ran into this lovely unmanaged exception.  Luckily, the fix is easy, because I knew exactly what I had done wrong.  I noticed there wasnt a ton out there on Google about it, so I figured I would post to help out others that might see it.  The error occurred when I was uploading a document based upon a custom content type.  After getting prompted to fill in metadata, the following error occurred.

COMException (0x81020037): The file blah.docx has been modified by domain\user.

I immediately knew what I had done wrong.  I forgot to turn off EventFiring before calling SystemUpdate().  This was in turn causing an Update event to fire which obviously wouldnt work because another Update event was alrady in progress.  If you don't remember how to turn off EventFiring, here is what the code looks like.

DisableEventFiring();
item.SystemUpdate(false);
EnableEventFiring();

MOSS Enterprise Search has proven to be a great tool for allowing users to search Line of Business systems and documents at the same time.  Out of the box, the Search Center provides some great looking search resuts.  However I keep hearing the same two things about it.

SearchStats Web Part does not display accurate results counts

This is becoming a fairly well known issue and I think its most likely by design, but it drives users crazy.  It doesn't seem to be an issue until you get a fairly decent amount of results.  I find that customers use this as a test of accuracy of your search index.  In a case where you are pulling data using the BDC from a LOB system, a lot of times the user knows that there are exaclty X widgets in that system.  So when the results count displays X - 373 items, they start asking questions.

Search Center does not support wildcard search

Pretty much everyone that has worked with Enterprise Search and has a SharePoint blog has complained about this one.  Microsoft decided to use keyword syntax for searching using the SearchBox web part.  Maybe, my post will be the 100th post and will get someone to consider doing something about it.  Normally this is fine but it doesn't support wildcard searching.  You would think you could just inherit from CoreResultsWebPart and change the way it gets the search results, but no someone decided it would be a good idea to mark the SearchResultsHiddenObject as internal.  Therefore, you really can't change the way this web part gets its results.  This means you would have to write your own CoreResultsWebPart from scratch.  This isn't inheritenly dificult because the search API is pretty easy to use and you can easily bind it to a ListView.  Of course by doing this, you lose connectivity to all the other web parts.  So that means you need to write connectivity to the SearchStats, Paging, BestBets, etc., web parts.  We should just be able to inherit from the existing parts right?  Nope, someone decided it would be a great idea to mark all of those classes sealed.  Honestly, why are these classes sealed?  That is rediculous.  So what it comes down to is that you have to rewrite the entire search center.  This is sad because the change required to implement wild card search could be done with about 2 lines of code.  Rewriting the Search Center is the approach Modosoft's Ontolica took.

I have mentioned in the past that Ontolica Wildcard Search is out there.  This product works fairly well at wildcard searching, it's free, but there are limitations in the free version.  The free version is basically a selling tool for their full product.  Ontolica took the approach that I described above and they created a whole new Search Center.  The full product is pretty nice and has nice grouping capability and various other ways to filter the data.  However, what I don't like about it is that it adds an additional layer of abstraction.  It requires you to map your managed properties to its own concept of properties.  Also it doesn't look like I can use the open source Search Facet web parts with it (someone correct me if I am wrong on this).  So in order to provide the same level of functionality, I would have to convince the client to fork over additional money to purcahse an Ontolica license.  That being said, if your client is willing to pay for a license, I do think it's a decent solution to the problem.  It has been a few months since I have looked at Ontolica, so if anything has changed with the product, feel free to let me know so I can take a look.

Things users like...

Ok, well I can't just focus on the things users complain about, because there are a ton of things they like.  They like being able to find all of their information in one place (espeically anything that indexes into other systems).  The Search Facet controls have always been a huge hit as well.  Users love drilling down into their data.

Anyhow, the point of my post today is to hopefully adds some more fuel to the fire and hopefully we can see a change some time in the future.

Sometimes when I am developing a feature that is deployed via solution, after I have deployed it to the server a few times, sometimes I think it is a good idea to just copy out my feature manually to the features folder.  I've got to get out ofthe habit of doing this, because it leads to nothing good.  If you keep files in source control, more than likely one of them might be marked as readonly.  Later when you deploy your solution file again, it will say the feature installed, but more than likely you will see a message like the following.

Executing solution-deployment-mysolution.wsp-0.  The solution-deployment-mysolution.wsp-0 job completed successfully, but could not be properly cleaned up.  This job may execute again on this server.
Operation completed successfully.

What this should really read is, "Something really screwed up while installing your deployment solution, but we're not going to tell you what it is and just make you think everything went fine."  Ok, admittedly this doesnt always mean something is messed up, but in this case, something definitely was.  I went back to my SharePoint site, and could not find my feature anywhere.  I tried retracting and deploying the solution and still nothing.

This meant is was clearly time to go sifting through logs.  It was then when I saw an excpetion that the solution could not copy a file because it was readonly.  To fix it, I retracted the solution and I also manually ran uninstallfeature using stsadm to make sure the features weren't registered in SharePoint.  I then physically deleted the feature folder in question from the SharePoint features folder and reinstalled the solution.

The lesson to be learned here is don't take shortcuts when developing and deploying features or if you do, make sure nothing is readonly or it will cause problems later.