Content Type is still in use

Sometimes you may be getting this error message when you think you shouldn’t be getting it:

Content Type is still in use   at Microsoft.SharePoint.Library.SPRequestInternalClass.SetListContentTypes(String bstrUrl, String bstrListName, String bstrXML, String bstrSqlPrefix, String bstrSqlSuffix)
   at Microsoft.SharePoint.Library.SPRequest.SetListContentTypes(String bstrUrl, String bstrListName, String bstrXML, String bstrSqlPrefix, String bstrSqlSuffix) 

This could happen either when you are trying to delete the content type via the SharePoint GUI or from your custom code. You may be thinking that this is incorrect, however have you considered this:

1) Actually you may not see documents that are using the content type because you don’t have rights to. SharePoint 2007 has item level security settings. So check all the documents in the list with an account that has full control (e.g. site collection admin).

2) If the list allows both minor and major versions and if any of the documents in the list is a minor version, but also has an existing previous major version (i.e. published version), then SharePoint will refuse to delete the content type if it is used by this last major version, even if the latest minor version is not using it.  I don’t have an explanation about why it is doing it, but this is how it works. It seems that you will need to check in a major version if you want to remove the content type in this case.

3) If the list has the ForceCheckOut flag enabled, then someone may have just added a document and may have not yet pressed “Check In” or may have pressed “Cancel” on the EditForm page. In such a case the document will be added to the list with version 0.1 but will be checked out to that user and will not show up for anyone else (including site collection admins). Actually even if you check through code the SPList.Items with elevated privileges account you will still not be able to see this item if it is not checked out to the elevated account.

One way to detect whether you are having such a “hanging” document is to check the SPList.ItemCount property and see if its value is the same as SPList.Items.Count. If they are different then you may have this type of “hanging” documents in your list. The ItemsCount seems to be stored in an internal array of list properties and counts all the items in the list, while SPList.Items will return only the items you can see.

public int ItemCount

{

    get

    {

        this.EnsurePropsFresh();

        return (int) this.m_arrListProps[20, this.m_iRow];

    }

}

SPTraceView – Lightweight Tool for Monitoring the SharePoint Diagnostic Logging in Real-Time

What it does

SPTraceView moniors in real time all SharePoint diagnostic tracing (also called ULS tracing) and can notify you using a balloon-style messages in the tray bar when any information of particular interest to you is sent (traced) by any of the MOSS services and components. For example if you haven’t disposed all SPSite/SPWeb objects properly from your web part, which also will cause unmanaged memory leak, you will see a message similar to the one below as soon as the page that contains your web part is rendered:

 

Because SPTraceView processes the tracing in real time you can identify errors and events as they happen. That is as soon as you interact with the SharePoint GUI when testing/debugging your custom SharePoint solutions including web parts, event receivers, workflows and all other SharePoint technology components.

SPTraceView is a very light weight software. It is a single 88kb executable file that doesn’t need to be installed and will work simply after you copy it to your machine. It can run in a farm and can provide the trace events from individual servers in the farm to a central location where you can monitor them in real time. It can also save the events of your particular interest in it’s own XML log files which you can review later. It can be also very useful to administrators for determining how healthy their SharePoint farm is.

 

Where to download it from

Use this direct link to download the 65 Kb zip file. No installation is required. It is a .NET application and will work on both 32 and 64 bit environments.

 

What information is traced

SharePoint provides diagnostics logging via ULS trace messages. Some (but not all) of the messages are saved by the SharePoint Tracing windows service in log files which reside by default under the 12 hive in the LOGS directory. Note that not everything is saved to those log files by default but everything is available to SPTraceView for real time analysis on the fly. Also most times it is unpractical to save everything as the log files will grow with gigabytes per day. To find out more about how to enable/disable the logging of various diagnostic categories check the SharePoint documentation or have a look for example at this post from the SharePoint Platform Team Blog:

http://www.sharepointplatform.com/teamblog/Lists/Posts/Post.aspx?List=427bfca2%2Db731%2D4c19%2D87c6%2D83c90460e02c&ID=48

Additionally Microsoft allows your custom applications to trace their own diagnostic information in the SharePoint log files. Your custom trace messages will also be available to SPTraceView. See this MSDN article about how to implement this sort of custom tracing.

 

More Information

More information about how to use SPTraceView and how it works is available on its own page.

Preserving the last “Modified By” when checking in a file

I’ve heard people saying that you cannot check in a file specifying explicitely who the “Modified By” user should be. Actually this is not true and you can do this easily through the object model using reflection and the code below:

public static void CheckInFileByUser(

    SPFile file,

    string checkinComment,

    SPCheckinType checkinType,

    SPUser modifiedByUser)

{

    MethodInfo mi = typeof(SPFile).GetMethod(

        “CheckIn”,

        BindingFlags.Instance | BindingFlags.NonPublic,

        null,

        new Type[] { typeof(string), typeof(SPCheckinType), typeof(bool), typeof(SPUser) },

        null);

 

    try

    {

        mi.Invoke(

            file,

            new object[] { checkinComment, checkinType, false, modifiedByUser }

        );

    }

    catch (TargetInvocationException invokeEx)

    {

        throw invokeEx.InnerException;

    }

}

Before calling this code you should check-out the file. If you don’t do so it will rethrow the “The file …. is not checked out.” SPException which will be thrown by SharePoint. The code will also bring all other SharePoint exceptions to you. And of course if you want to preserve the last “Modified By” user when updating your file using this function, just pass the file.ModifiedBy as the user argument retrieved before the file was checked out.

Show an “Operation in Progress” page from your code

You can also show the nice animated message that SharePoint shows on long operations from your web parts and web controls as the one below. This is actually very easy to be done.

You just need to use the SPLongOperation class. Specify the custom message to be shown, then call Begin() method to show the “Operation in Progress” page and then start doing your long operation stuff. When ready you call End() passing a URL to be redirected to. If an exception occurs you may also redirect to the standard error page as shown in the code below:

try

{

    using (SPLongOperation ctx = new SPLongOperation(this.Page))

    {

        ctx.LeadingHTML = “Please wait while your operation is being executed.”;

        ctx.TrailingHTML = “Your current operation is currently being executed. Please be patient. Blah blah blah.”;

        ctx.Begin();

 

        MyLongRunningOperation();

        ctx.End(SPContext.Current.Web.Url);

    }

}

catch (ThreadAbortException) { /* Thrown when redirected */}

catch (Exception ex)

{

    SPUtility.TransferToErrorPage(ex.ToString());

}

Because when an HTTP redirection is done from ASP.NET a ThreadAbortException is thrown, we have to catch this exception in its own catch block and ignore it.

For more info check the MSDN documentation of the SPLongOperation class here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splongoperation.aspx

ForceCheckOut and how it affects development

Document libraries in SharePoint have a “Require Check Out” flag which is part of the “Visioning settings”. The flag corresponds to the SPList.ForceCheckout property in the object model. This flag is very good if you don’t want your SharePoint users to worry about checking out files. The files will be automatically checked out every time whey edit a document if this flag is turned on. However this will also affect your code if your are working with documents and metadata.

“Require Check Out” is “No”

When users upload a document it will be automatically checked in. Then they will be redirected to the EditForm.aspx and the buttons will be “OK” and “Cancel”. If they press cancel at this stage the document will appear in the document library as checked in.

In  the same time when you add a document using the SPFileCollection.Add() method, the file will be added with a checked in status.

“Require Check Out” is “Yes”

When a document is uploaded from the GUI it will be created and then will be automatically checked out by SharePoint (This is done on OnSubmit() in the Upload.aspx page). Then the user is redirected to the EditForm.aspx page and the buttons on the page will be “Check In” and “Cancel”. If the user presses cancel at this stage the document will appear in the document library as checked out (it will just keep its checked out state). If the user clicks “Check In” the document will be checked in overwriting the current checked out version and you will end up with only 1 version (which is expected).

In your code, when you call SPFileCollection.Add() method to add a document as soon as the method returns the document will have status checked out. So if you now try to call SPFile.CheckOut() to do further processing as you would if you were working with a document library that had “Require Check Out” set to false, this will throw an exception.

Also if you have an event receiver defined for ItemAdded and you run code with elevated privileges recreating the SPSite, then the document will not appear for you because it has been just added and the only existing version is not checked out to the administrator (the elevated privileges account). So in your event receiver code make sure to use the ListItem from the provided properties rather than getting a new list item from the recreated SPSite under the elevated privileges account.

Compiling SharePoint Solutions on 64bit

Undoubtedly 64bit is the future of the software, however the transition from 32bit won’t be painless. As some of you may be thinking about moving to 64bit platform for SharePoint development or have already taken the plunge here are some lessons learned and frustrations from building SharePoint solutions on 64bit Windows 2003 using VS.NET 2005 + SP1 and Microsoft.NET Framework 2 + SP1 (32 and 62 bit)

1) First of all you should know that VS.NET 2005 is a 32 bit application. It will not work flawlessly on 64bit so be prepared that it will not behave. For example if you are running more than one instance of VS.NET in the same machine (even in different desktop sessions) sometimes it will just crash.

2) The Visual Studio 2005 extensions for Windows SharePoint Services 3.0 don’t have 64bit support at all, which means that you won’t be able to use any of the SharePoint projects for VS.NET in 64bit environment.

3) If you are building “ASP.NET Web Site” or “ASP.NET Web Service” then you may get this error:

Could not load file or assembly ‘Microsoft.SharePoint.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies.

If you just copy the 64bit version of Microsoft.SharePoint.Search.dll assembly from the SharePoint 2007 hive to your application BIN folder this will make the things even worse and you will start getting random errors. Some of them may be:

Attempted to load a 64-bit assembly on a 32-bit platform. Use ReflectionOnlyLoad() instead if trying to load for reflection purposes.  

There is a circular dependency in the target dependency graph involving target “Build”.

aspnet_compiler.exe” exited with code -2146233082.

Failed to create AppDomain.

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

In order to solve the error you have to copy the 32bit version of the Microsoft.SharePoint.Search.dll (from a 32bit deployment of SharePoint) and copy it to your web site BIN folder as this is suggested in the following post.

A better solution could be to use an “ASP.NET Web Application” / “ASP.NET Web Service Application” projects instead of “ASP.NET Web Site” / “ASP.NET Web Service”. These project are available from File -> New -> Project -> Visual C#/VB.NET -> Web.