A tale of three guids

A tale of three guids:

Sharepoint

Features require a guid of the form “this-is-a-guid”

For a content type you need a guid of the form “0x100thisisaguid”

For a field definition you need a guid of the form “{this-is-a-guid}”

 

One team, three distinct guid formats WTF

Debugging Feature Receivers

A great technique when developing a sharepoint feature receiver:

Create yourself an announcements list and have the feature log the install (or failure to do so) to this location.

 This is much less messy than debugging on a production box.

 This announcement list can be locked down so only developers and admin’s can read it.

 I have found that you can create and populate a custom list and a view in 20 lines of code (genericly).

 This contrasts to 4000 lines of xml per list/view.

TFS fails as version control software

TFS is inadequate as a VCS.

The developers think that all development occurs in VS.NET.

This does not work if you use code generation

Example

I have a spreadsheet that I was to control in VCS.

If I lock the file and then replace it I get a (false) claim that the file has not changed – which automatically unlocks the file.

In order to get the file checked in I need to edit another text file in Visual studio.  By changing this it notices that both have changed.

Example

Why can’t it perform keyword expansion like every other modern vcs!

Enterprise Search and the BDC

This is an article on configuring the BDC to work with Enterprise Search.

The BDC is a database/web service abstraction layer that provides a unified api.
It claims to be of general use in Sharepoint.

I can see little benefit to it if you don’t want google like searches of your application.
The big problem is that you need to be very careful or the search mechanism will invalidate any access controls that you have.

The BDC is excessively complex for what it provides.  The price in it’s complexity (as is generally the problem with sharepoint) exceeds the effort required to roll it yourself…