• SharePoint 2010 Foundation (previously known as WSS 3.0) comes included with Windows 2008 Server Standard edition. You need Windows Server CALs for user access.
• SharePoint 2010 Server is a server product that you install on-top of Windows 2008 Server and is licensed separately per server. You may see “Standard” or “Enterprise” but the server product comes in only one version and has only one SKU.
• Standard & Enterprise CALs (client access licenses). Each user connecting to a SharePoint server needs a standard CAL. For users accessing enterprise features, they also need an enterprise CAL. Note – its not one or the other, but both (Standard with Enterprise CALs) if you decide to use  any of the enterprise features.
• Summary of Enterprise CAL features -
  • FAST Search Centers
    • Sorting by any managed property
    • Contextual search results (i.e. user or audience targeted)
    • Refinement filter counts
    • Similar results
    • Thumbnails and previews
    • Visual best bets
    • Scale and other search platform enhancements
  • Business Intelligence
    • KPI’s
    • Chart Web Parts
    • Dashboards
    • Data Connection Library
    • PowerPivot for SharePoint
  • Access Services
  • Excel Services
  • InfoPath Services
  • Visio Services
  • PerformancePoint Services
• Microsoft FAST Search Server for SharePoint – if using FAST Search Centers as part of the Enterprise CAL, you need a separate server license for each FAST server that will actually index and crawl content. Vice versa, if you want to implement Microsoft FAST Search – you need Enterprise CALs to access the search centers within SharePoint 2010.

Note, the above covers mostly intranet/extranet scenarios. Microsoft have specific versions of SharePoint 2010 for Internet sites that may also require Window External Connector licenses for your Windows 2008 servers, these versions also have Standard and Enterprise features and can be used with Microsoft FAST Search.

In addition to the above, the following links are also great resources for understanding SharePoint 2010 licensing

• http://www.sharepointconfig.com/2010/05/indicative-sharepoint-2010-licencing-costs/
• http://community.bamboosolutions.com/blogs/sharepoint-2010-price-calculator/default.aspx

http://code.msdn.microsoft.com/SPSolutionExtractor

Be wary though – the author of this tool doesn’t seem familar with command line tools.  Not only is the executable’s name far too wordy, certain menus and prompts seem to lack polish, however it does get the job done.

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
    }
}

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.

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.

How are you supposed to 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.

What is CAML? Officially, it stands for Collaborative Application Markup Language. 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.

Enter Linq, with its terse sql-esque statements and amazing chainability. 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