Recently I updated the Internet Explorer on one of my SharePoint Development Servers to IE 10. Since then I wasn’t able to script debug directly in Visual Studio 2010. The problem was whenever I tried to attach to the Internet Explorer process I got the error message that a debugger is already attached to this process.

Cannot connect to iexplorer process

The reason for this problem can be found in the wrong registered “msdbg2.dll” of IE 10. What needs to be done is to re-register the dll in 32-bit mode.

First start the cmd.exe in 32-bit mode. For this you need to run “C:\Windows\SysWOW64\cmd.exe
In the command line execute the following command to re-register the dll.
regsvr32 “%ProgramFiles%\Internet Explorer\msdbg2.dll”

Re-register msdbg2.dll

Once this is done restart your Visual Studio 2010 and now the debugger should be able to connect again to the Internet Explorer process.

The solution for this I found with some luck at Microsoft Connect and worked well for me.

In this article I like to show you my way to deploy lookup fields to SharePoint declarative. I need to note that I won’t do this fully declarative but found a solution that works best. This will be used by SharePoint internally and is fully supported. The lookups I’m talking are lookup fields deployed as site column.

Whenever it comes to content types and site column in my opinion the best way is to create them declarative. The reason for this is that I can handle that all deployed fields have the same GUID that I defined and every Site Collection has the same fields with the same IDs. Simple field types such as text, number, Date and Time, User Fields, Yes/No Fields can be created easily using the declarative approach but with lookup fields this can be a little bit trickier. During the last weeks I did a couple of interviews with Becky Bertram, Doug Hemminger and made a poll on SPYAM. The result of this was that most people deploy or create lookup fields using code and not using the declarative approach. Here is the result of the poll.

SPYam Poll for creating lookups

SPYam Poll on how creating lookups as web site columns

But now let’s take a look how to create a lookup field.

Creating the Lookup Field

The basic declaration of a lookup field looks simple and you can reference the List by using the URL of the web where the site column will be deployed to. This can be done according to the documentation as long as the list will be deployed in the same feature as the lookup column.

In a second module I created a basic list instance with a custom list.

Both elements will be deployed in the same feature which means that the reference of the lookup should match the list and replace the token List URL with the value for “Lists/Colors” with the GUID. The problem is that after the deployment the lookup column looks like this.

Lookup field after declarative deployment

Lookup field after declarative deployment

If you go to the definition of the lookup column the list is empty and won’t be displayed correctly and the field won’t work with lists. The empty “Get information from” is one reason that people create lookup fields using code. As always in SharePoint many ways lead to a solution and a lot of people have created their own provisioning classes to create site column lookup fields, but here comes the good news. This problem can be fixed some simple modifications of the field configuration using code.

Fixing declarative Lookup Field

From my experience the problem is that SharePoint won’t replace the List URL token with the GUID of the list and the web. When you like to use site columns as lookup fields than you have to get those GUID somehow to the schema of the fields. The URL token in Site columns cannot be used because site columns need to have a reference to the GUID of a list and a web. Then SharePoint will be able to find the matching list and web where the lookup should reference to. A sub site cannot make use of a list with the value “List/Colors”.

A quick solution would be to create the list first and the web first and add the GUID in the field definition. Works great as long as you don’t like to reuse the lookup field in another site collection. In this case you have to change the GUID when you like to deploy the solution to another web application or sites. Not really a great option.

My solution is to add the GUIDs to the schema of the field definition and use the List URL as a token to find the proper list. This can be done with a simple feature receiver. The code for this looks like this.

The code above does the following tasks:

  • Get the Field
  • Get the list that should be referenced by the lookup
  • Change SourceID and List to the GUID of the web and list.

Without using the feature event receiver the field looked this:

After the deployment with the feature event receiver the field looked like this:

SharePoint incremented the version number of the field after the changes have been applied to. The manipulation of the schema using the object model is fully supported by SharePoint but you need to take care that your modification are set with a proper xml that matches the field schema definitions. You will find this comment in the SPField.SchemaXML on the MSDN. There is not much difference in setting the schema of a field or create a field directly from XML using AddFieldAsXML.

A second look to the column settings shows that everything will be displayed correctly.

Lookup field after modified schema

Lookup field after modified schema using feature receiver

If you like to try this yourself you can download the solution N8D.Lookup.

Some other recommended Information on lookup fields I used previously was.

At the SharePoint Conference 2011 I had a discussion with Christian Ståhl and Laura Curtis if it will be possible to cleanup old versions in SharePoint using a script or command line application. I thought to myself that this should be a big task to accomplish but a useful. The slow way to clean up old versions is to loop through all the site collections, webs, lists and items. From each item check the versions and delete them. In SharePoint 2010 Server there is a much smarter way to do this by using a helper that exists in SharePoint Server. The class I’m talking about is called ContentIterator and can be found in Microsoft.SharePoint.Server.Utilities namespace.

The smart thing about the ContentIterator it prevents SharePoint from blocking the database with requests. The only side effect of this is that items in the meantime can be modified because this method is not thread safe.Continue reading

The upcoming version of Internet Explorer is near at first public beta. The main features of the new Microsoft Browser is focused on performance and web standard compliance. Over the last couple of weeks the last technical preview was released and the first public beta will be released on 15. September 2010.

One of the new mayor benefits in IE9 is a whole new reengineered Javascript engine named Chakra. It has the ability for better useage of multi core CPU’s. In the SharePoint 2010 the new user interface use many javascript for rendering the menus. So what could be better as a solid fast browser engine.

First of all the good news. SharePoint 2010 and IE9 works as expected, which i find quite impressing for a pre-beta technical preview. As expected the Performance of SharePoint 2010 is much more better than on IE8. Currently i haven’t done any benchmarks but from my point of view loading IE9 loads 50% faster than IE8.

If do a test yourself you must be carful because IE9 try to load SharePoint 2010 in IE8 document mode. This behaviour could be switched using “Debug” menu or simply press ALT+9 Shortcut. Only with those setting you will get the best out of performance.

The latest pre-beta of IE9 is avaliable http://ie.microsoft.com/testdrive/.
Hopefully the beta will do the job quite well too.

Let’s give it a try and tell me what you think about SharePoint 2010 and IE9.