Cannot connect to the SharePoint site in Visual Studio 2010

When creating a SharePoint in Visual Studio 2010 on a SharePoint server, you may still get the error : "Cannot connect to the SharePoint site":



You are using a site collection administrator account but the problem is that the site collection admin account doesn't have access to the SP config database and content database. Note that Visual Studio goes against the API directly so it can't do anything until it can read from the database. Here's what's in the SP log:

02/17/2012 15:08:49.68 vssphost4.exe (0x071C) 0x136C SharePoint Foundation Database 880j High SqlError: 'Login failed for user 'us\siteAdminDeveloper'.' Source: '.Net SqlClient Data Provider' Number: 18456 State: 1 Class: 14 Procedure: '' LineNumber: 65536 Server: 'US.local,1433'
02/17/2012 15:08:49.69 vssphost4.exe (0x071C) 0x136C SharePoint Foundation Database 3351 Critical SQL database login for 'SharePoint_Config' on instance 'SqlHost' failed. Additional error information from SQL Server is included below. Login failed for user 'US\siteAdminDeveloper'.

Since you are doing development on SharePoint, use an account that's an Farm Administrator to avoid problems like this.

Build SharePoint 2010 projects without SharePoint 2010 installed

Many developers have resorted to creating a virtual machine that has SharePoint 2010 and Visual Studio 2010 installed in order to develop Sharepoint projects. Or have both installed directly on a Windows 7 machine. I personally don't like either because the former setup is outrageously slow on almost any laptops, and the latter has an entire SharePoint hogging the Windows 7 machine all the time. I would rather work in the Visual Studio 2010 on my Windows 7 laptop, and deploy to a remote dev box or VM, which runs SharePoint only. Here's how to set up a Windows 7 machine with Visual Studio 2010 to fully develop and build SharePoint 2010 projects:

• Create the folder C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14 on your Windows 7 machine
• Copy the \14\ISAPI folder from a machine with SharePoint 2010 installed to the above folder. This way the assemblies are in the same location as they are on the SharePoint server.
• Download Microsoft Chart Controls for Microsoft .NET Framework 3.5 and install it on the Windows 7 machine. Several SP 2010 assemblies (Microsoft.Office.Server, Microsoft.SharePoint.Taxonomy, etc) depends on System.Web.DataVisualization v3.5 in this package. The package installs to C:\Program Files (x86)\Microsoft Chart Controls and also puts assemblies in GAC.
• Add the above assemblies to be recognized by Visual Studio 2010 by default (that is, show up in the Add Assemblies Dialog when clicking Add References. This is not absolutely necessary but makes life a whole lot easier. The registry entries also allow projects created on machines with SharePoint installed to be compiled without having to change anything, as some of the referenced assemblies are in the GAC on the SharePoint machine, and hence no path is specified in the project file.
  
• Add the registry key:[HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\v3.5\AssemblyFoldersEx\SharePoint] and give the default string the value of the path to the ISAPLI folder: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI
  Visual Studio will display the assemblies in the Add Reference dialog for all SharePoint 2010 projects (which target .NET 3.5). Note that this must be added under the CURRENT_USER registry. The assemblies do not show up when this is added to the LOCAL_MACHINE registry, though Microsoft says either works.
  

For developing Silverlight 4 components for SharePoint 2010, do the following additional setups

• Copy the \14\TEMPLATE\LAYOUTS\ClientBin folder from the SharePoint 2010 machine to the 14 folder created above. If you develop Silverlight 4 components for SP 2010, you need the two assemblies in this folder.
• Add the above assemblies to be recognized by Visual Studio 2010 by default (that is, show up in the Add Assemblies Dialog when clicking Add References. Add the registry key:
  [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Silverlight\v4.0\AssemblyFoldersEx\SharePoint] with the deafult string value of C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin
  Visual Studio will display the two assemblies in this folder in the Add Reference Dialog for any Silverlight 4 projects. Note adding this key to the LOCAL_MACHINE registry is fine.
• Download and install Silverlight 4 Tools for Visual Studio 2010 if it's not installed.
• Download and install Silverlight 4 Toolkit if it's not installed. It's not essential but most likely you'll need the toolkit.

Then you can develop SharePoint projects comfortably in your Windows 7 machine, deploy to and remote debug on another machine that runs SharePoint.

SharePoint custom field definition considerations

When defining custom fields in XML for SharePoint, the element has numerous attributes and most of them are optional. It's important to think through.

I recently came across some fields defined with Sealed="TRUE". This attribute prevents the deletion of the column from a list once it's added (either added directly or by adding a content type that has this field). It's a good idea to enforce metadata consistency this way. However, what if a user mistakenly add a content type that has this field to a list, and then want to remove it? Well, there's no way unless writing a utility to delete it from the list using the API:

int fieldCount = l.Fields.Count;
for (int i = fieldCount - 1; i > -1; i--)
{
SPField f = l.Fields[i];
if (f.Group == "MyGroup") //or other criteria
{
Console.WriteLine(f.StaticName + " " + f.AllowDeletion.ToString());
f.AllowDeletion = true;
f.Sealed = true;
f.Delete();
}
}
l.Update();

There is also the attribute of AllowDeletion. Interestingly, If AllowDeletion="TRUE" and Sealed="TRUE", the column can be deleted. AllowDeletion appears to have precedence. Need to do some research to figure out the exact differences between the two.

SharePoint 2010 Custom Content Types and Fields Gotchas

If you have existing custom fields and custom content types that were created and deployed to MOSS 2007 successfully, and now you want to deploy them into SharePoint 2010, there may be a few things that'll surprise you. I went through a lot of pains to get it done successfully and the following is maybe a subset of all the gotchas out there.

Custom fields and content types are typically deployed in a wsp package and then activated via feature. Theoretically there should not be a problem to take such a wsp and deploy directly into SP 2010. However, there are some small changes (and bugs also?) in how SP 2010 handles fields and content types. The following were experienced on SP 2010 with August 2010 CU.

1. Your content type xml definition contains comments between the tag, which you often do, as it's a good practice to explain what the fields included are and where they comes from. Then after a successful deployment, the Manage Content Type page shows none of the fields included in for the content type (Site Actions -> Site Settings -> Site Content types -> (select the content type, _layouts/ManageContentType.aspx). Looks to me like the code that reads the xml definition doesn't exclude comments node. Huh, Microsoft?
   
   
2. Overwrite attribute. This behaves differently now, as detailed in this blog. Bottomline is, set this to try in development. Otherwise you can't deploy and then activate the feature with updated XMLs if a previous deployment failed and left phantom pieces in the farm.
   
   
3. Inherits attribute. By default in SP 2010 a custom content type only has the fields defined in its node, unless Inherits="TRUE". This is a change of the default behavior from WSS 3.0.
   
   
4. SourceID attribute. This specifies the schema http://schemas.microsoft.com/sharepoint/v3. Not sure what I was thinking, maybe just wanted to be cool, I changed this to http://schemas.microsoft.com/sharepoint/v4. And it caused some weird errors logged (Can't find the XML schema definition or something?). I definitely need to read up on what the differences between the two schemas. It appears that the majority of the schema definitions that SP 2010 uses is still in v3. So leave the SourceID value as v3.

I still have not quite figured out how to completely clean up a failed deployment or retraction, which may leave behind field defs or content type defs that are nowhere to be found in the UI, database tables, and API (SPWeb.Fields, SPWeb.ContentTypes), but nontheless lurks around and prevent activating the updated feature (Log shows exception that the ID already exists, or can't overwrite etc). People suggests to change the GUIDs of the feature, fields, or content types to get around the issue but it's not always practical.

SP 2010 SPSite FileNotFoundException

SPSite site = new SPSite("http://domainname/sites/sc");

is a frequently used statement to open a site collection on a SP server, particularly from a separate application (Console App, ASP.NET app) to look inside the SharePoint. A frequently encountered problem is that it throws a FileNotFoundException:

"The Web application at http://domainname/sites/sc could not be found. Verify that you have typed the URL correctly. "

Of course the URL is correct. In a SP 2010 dev environment, you'll almost inevitably run into this the first time. What the problem is, SP 2010 is 64 bit only. And by default, Visual Studio compiles your Console, WinForm, Asp.Net projects in 32 bit. So you need to change it: Go to the project Properties -> Build -> Platform target, change to either either x64 or Any CPU. Build again, and the error goes away.

MOSS 2007 64 bit would cause this problem too but since developers often install 32 bit for dev purpose, it's encountered less frequently.

Failed to create field: Field type myfield is not installed properly

You have seen this error in MOSS 2007 and it's the same in SP 2010:

"Failed to create field: Field type is not installed properly. Go to the list settings page to delete this field."

This can happen when you activate or deactivate a feature that includes this field. The message is not helpful. There are plenty of discussions about this and apparently a gazillion scenarios that this could occur. In my case, it's because myfield is a custom field inherited from SPFieldMultiColumn. And I didn't include the class (and the assembly) in the deployment. Hence when it goes to create or delete the field, there's nothing other than the metadata in the XML field definition.

So at least one scenario cleared up.

prompted for login and then 401.1 Access Denied when accessing Shared Services

Many people have written about this problem. When you are in the SharePoint Central Administration site, and click one of the Shared Services you created on the left Quick Launch menu (e.g. SharedServices1), you are prompted for login repeatedly and it eventually shows your the 401.1 Unauthorized: Access is denied due to invalid credentials error.

I have summarized below the possible causes and fixes that I have found on the web:

1. Because the SSP URL has a domain name different from the machine name. This is almost always the case. A security feature called "loopback check" introduced in Windows 2003 SP1 and onward is the reason fro this. Apply a registry change on the server by following the MSFT support at http://support.microsoft.com/kb/926642/
   
   
2. Because the name of the SSP you created (e.g. SharedServices1) happens to be the same as the name of the AppPool for the SharePoint Web Application that hosts the Shared Services Admin site. They must be named differently as the SSP instance will creates a AppPool automatically under its name.
   
   
3. The SSP site collection administrators has only one user account. Not sure why this is would be a problem but adding a secondary administrator to the site collection helped with some of this error.