The following tool makes quick work of trying to find differences in the GAC for remote servers and evens offers up a nifty HTML report. Very nicely done.

http://gaccompare.codeplex.com/

A couple things – you need to have Admin rights on the remote computers, the tool does take a while to do the compare (so be patient) and to get the HTML report and other cool features, right-click in the results pane after it has loaded.

The WebDeleted.aspx page references the simple.master page which we redirect to our customized application master page. Apparently this results in the page trying to load in elements that are out of context for it. The solution was to stop redirecting simple.master and instead route it back to the SharePoint out of the box simple.master.

So with the three columns, the following CAML query can be used to query items that should be currently displayed:

SPListItem item = GetItemFromSomeWhere();

if (item.ParentList.BaseType == SPBaseType.DocumentLibrary)

{

// This item is from a document library – it probably contains a file.

}

The underlying problem is caused by a poorly written function called GCComputeSizing within Core.js The common fix is to override this function by defining your own function called GCComputeSizing in a script reference that is loaded in after the reference to Core.js is called in your master page.

However, what most of the other blogs and resources fail to mention is that Core,js can sometimes be loaded in using the “defer” attribute of the script tag. When this happens, core.js will now be loaded in after the page is loaded. Unless you also defer your override script, you will invoke the built-in GCComputeSizing function and the bug will persist.

This problem was specifically noticed when using user-defined or custom datasheet views. Comparing the source html for standard and custom datasheet view yieled the following:

Standard Datasheet View:
<script type=”text/javascript” language=”javascript” src=”/_layouts/1033/core.js”></script>

Custom Datasheet View:
<script type=”text/javascript” language=”javascript” src=”/_layouts/1033/core.js” defer></script>

As you can see, only custom datasheet views were loading in core.js  as a deferred script. Adding the defer attribute to our custom override script fixed this problem by deferring the override after the deferred core.js was loaded.

In terms of overriding GCComputeSizing  there are many examples easily searchable through the interwebs. One word of caution though, as a person who has quite a bit of experience with Javascript, GCComputeSizing not a function suitable for production. Even some of the *corrected* versions that others have posted still make me uneasy. Anything that has the potential of throwing a client’s browser into an infinite loop and locking up their cpu is a serious  cause for concern. Fortunately, our customized design uses a fixed layout so I was able to simplify GCComputeSizing to the following:

function GCComputeSizing(GCObject)
{
    if (TestGCObject(GCObject))
    {
      var lGCWindowWidth=663;
      var lGCWindowHeight=550;

      glGCObjectWidth = lGCWindowWidth;
      glGCObjectHeight = lGCWindowHeight
    }
}

I think by now you can guess that would be too easy. So instead of divulging into my usual SharePoint scarasm, I’ve found a friend who has done a much better job than I could ever pull off.

http://www.sharepointsecurity.com/sharepoint/sharepoint-development/splistitemurl-funky-return-fiesta/

One or more field types are not installed properly. Go to the list settings page to delete these fields.

Wonderful, eh? Don’t believe it, you don’t need to delete any fields. You more than likely have a misspelled column or a column name that has a different internal name than what is publicly visible. For example, a default SharePoint calendar has a column field called “End Time”; however if you include the space within your query, you’ll get the error above. In this case, the internal name is really “EndDate”. Also look for column fields that have been renamed. Sometimes if you define a column, then later change its name – the internal name will still remain the same.

So this begs another question – How are you supposed to *magically* know what the internal field name is? Well, here’s a tried and true method. Go to the list you are trying to query from, then click Settings -> List Settings. Scroll down to where all the Columns are defined. Click on the one in question, which will take you to the FldEdit.aspx page. Within your address bar, notice the querystring param Field. This references the internal field name for the column which you should also use in your queries.

See Microsoft,  wasn’t that a lot more helpful then trying to tell the user to delete some random field from their list? Geesh.

What is CAML? A pain in the arse. Officially, it stands for Collaborative Application Markup Language – which amounts to more bollox than telling you anything you need to know. Essentially, CAML is an xml structured intermediate query syntax for SharePoint to query against data structures (that can also be defined using CAML). Sounds a bit like SQL no? Well guess what CAML gets translated to in the back-end? Yep – SQL. SharePoint takes your CAML and queries against its sql backend. So in short, with CAML you have this massively verbose query syntax that requires nested xml tags, multi-line statements, and quoted attributes – yuck!

Enter Linq, with its terse sql-esque statements and amazing chainability. Yay! No more CAML!!

Not quite.

Linq can only be used against a SPListItemCollection object which must be filled before use. The two most common ways to populate a SPListItemCollection is to either Get all items, or use a SPQuery object and CAML syntax to get a subset of items. As you can see, the dilemia presents itself that if you try to avoid CAML altogether, you will sacrifice performance when querying a list with potentially a large set of items.

So the best solution? Use both. Before using Linq directly to query items, first populate your SPListItemCollection with a CAML query that will do an adequate job of ensuring a manageable subset returned from the database. Then with Linq, fine-tune your SPListItemCollection to further sort and filter your result set. So Caml – Chainsaw, Linq – Carving Knife.

For more information, check out the excellent resource below: 

LINQ and SharePoint Development: The benefits and the pitfalls