Merry Christmas and Happy New Year

Happy holiday everyone :) 

SharePoint 2010 Limitations

Rodney, one of my colleague shared interesting facts about SharePoint 2010 limitations today.

There are a few “interesting” limitations.

Limit	Maximum value	Limit type	Notes
List row size	8,000 bytes per row	Boundary	Each list or library item can only occupy 8000 bytes in total in the database. 256 bytes are reserved for built-in columns, which leaves 7744 bytes for end-user columns. For details on how much space each kind of field consumes, see Column limits.
Items	30,000,000 per list	Supported	You can create very large lists using standard views, site hierarchies, and metadata navigation. This value may vary depending on the number of columns in the list and the usage of the list.
List view lookup threshold	8 join operations per query	Threshold	Specifies the maximum number of joins allowed per query, such as those based on lookup, person/group, or workflow status columns. If the query uses more than eight joins, the operation is blocked. This does not apply to single item operations. When using the maximal view via the object model (by not specifying any view fields), SharePoint will return up to the first eight lookups.

For more details please see: http://technet.microsoft.com/en-us/library/cc262787.aspx#ListLibrary

Have a great day J

Using Fluent NHibernate in SharePoint 2010

Most of the time when developing with SharePoint 2010 we don’t have to use any ORM mapping because SharePoint’s API take care of 99% of our needs. Today I had to use Business Connectivity Services to expose data in a third party database as External List.

When defining Business Connectivity Model in SharePoint project we have to write (at least) our own ReadList and ReadItem methods.

My implementation of ReadList and ReadItem were pretty simple:

        public static MyEntity ReadItem(string id)

        {

            var session = SessionSource.Current.GetSession();

            var repository = new Repository<MyEntity>(session);

            return repository.GetById(id).ToEntity();

        }

        public static IEnumerable<MyEntity> ReadList()

        {

            var session = SessionSource.Current.GetSession();

            var repository = new Repository<DomainObject>(session);

            var results = repository.ListAll();

            return results.Select(x => x.ToEntity()).ToList();

        }

Those 2 methods worked fine in the Unit Test. However (as usual) when running in SharePoint’s environment they fell apart.

After a lot of hours in debugging finally I managed to make they work.

These are a few things you might want to check when using Fluent NHibernate with SharePoint 2010:

1. Make sure you include ALL dlls which came with Fluent NHibernate in the package with GlobalAssemblyCache as the target deployment (Business Connectivity Model will have to be deployed as a farm solution).

2. Add qualifyAssembly tags for all those dlls to your web config to tell NHibernate to load those assemblies from the GAC instead of the bin folder.

After completing those 2 steps my ReadList and ReadItem work as expected J

Hope this helps J

SharePoint 2010 and .NET 4.0

This morning, I tried to change the target framework of my SharePoint 2010 projects to use .NET 4.0; however the .NET Framework 4.0 option was not visible for some reason.

Clicking on the “Install other frameworks…” brought my IE to the Microsoft .NET 4 framework download page (I ended up downloading the .NET 4.0 and repair my installation). However after rebooted the server, the option to target .NET 4.0 still was still missing.

A quick Google search told me that SharePoint 2010 does not support .NET 4. It runs on .NET 3.5 only (at least not yet). Surely there will be a service pack to tackle this issue in the near future.

So a tip for all of you who are planning to use .NET 4.0 for your SharePoint’s development: don’t do it (not yet).

Have nice Thursday J

Evan Putranto

Visual Studio 2010 debugger not stopping on SharePoint 2010 breakpoints

One of my work colleagues shared something which I think is very useful today, so I thought I should share it in here.

Occasionally, when trying to debug SharePoint 2010 codes by attaching the debugger to the w3wp.exe process, the debugger does not stop on any break points. The problem is seems to be due to Visual Studio 2010 and the version of .NET framework used.

When attaching the debugger, Visual studio by default automatically determines the code types to debug (Managed, Native, Script, T-SQL etc). With Visual Studio 2010 however, there’s now 2 Managed code types (v2.0, v1.1, v1.0) and (v4.0), because we are still using .NET 3.5 occasionally Visual Studio gets confused and automatically determines 2.0 managed code as 4.0 managed code. This causes the debugger to be successfully attached but not to stop in any breakpoints.

By setting Visual Studio to always manually debug on Managed (v2.0, v1.1, v1.0) and T-SQL seems to fix the problem. It’s been working consistently so far.

Screenshot:

Visual Studio 2010 Debugger

Have a nice day :)

Evan Putranto

HttpRunTime.Cache & ReaderWriterLock

Yesterday there we had a big problem with one of our client website. It was using 100% CPU and chewing all the memory it can get. Yes it is a retail website (a lot of visitors visiting the website every second). However it still shouldn’t bring all other website in the server down and unresponsive.

After some investigation I found out that the cache manager (where we use HttpRunTime.Cache) uses a lock during insert and remove item method call. It should use a lock because there will be multiple request happening at the same time. If we don’t use any lock some of the data returned to the browser might be corrupted.

However because we were using a normal lock what happen was all the request queuing to get a slice of time in the cache even when it was only trying to read. As more visitors visiting the website the longer the queue and the more memory they use.

I remember I used ReaderWriterLock in the past and I found it very useful especially in the situation like this. So I decided to change the lock to use ReaderWriterLock. And wallah it worked like magic and instantaneous drop in the memory usage and CPU time.

So this is my first tip: Cache & ReaderWriterLock are best friends J

Have a good day.