FileNotFoundException with "new SPSite" Call

This one came back to bite me again, so time to note it down here - when running any test code which accesses a SharePoint web or site using new SPSite(url) in a console application, or in a Visual Studio 2010 test project, it is necessary to adjust the build properties of the project.

The project build configuration (the second tab down in the project properties) need to have the Platform Target explicitly set to x64. If this target is set to x86, or possibly to "Any CPU" then the call to "new SPSite" will fail with "FileNotFoundException", stating that "The web application cannot be found". Next time I'll remember...

Error in Visual Studio 2010 Packaging a SharePoint 2010 Solution

Was getting an error stating that a file "deploys to the same package location" when packaging a SharePoint 2010 solution in VIsual Studio 2010.

Turns out that the SharePointProjectItem.spdata file (in the module subfolder within the Visual Studio project) had somehow gained duplicate entries for a particular file.
To fix this,

1. Unload the project in VS (or close the entire solution)
2. Find the SharePointProjectItem.spdata file in Windows Explorer, and edit in Notepad++ (or your favourite text editor!) to remove the duplicate reference
3. Reload the project in VS, and select that "Package" action - all then worked for me.

Cannot Log in with Microsoft Lync

Took a while to track this one down - a fresh install of Lync refused to connect or login to Office 365. Experimented with adjusting the manual configuration settings as suggested by lots of posts, but to no avail. Finally found a comment on a forum suggesting to check the time on the computer. The time was in fact a few minutes fast - so I set the time, restarted Lync, and login worked straight away. Who'd have thought?!

Cant Seem to Remove Columns from a Content Type in a Solution

Some behaviours in SharePoint 2010 solutions have become frustrating compared with SharePoint 2007 solutions. One that's particularly troublesome is attempting to modify site columns in a custom content type that inherits from a non-built in content type.

When inheriting from a publishing article page content type using a solution,  just can't seem to remove a couple of site column. Neither of the following approaches seems to work. If I come up with a solution, I'll add it hear.

            <FieldRef ID="{d3429cc9-adc4-439b-84a8-5679070f84cb}" Name="ArticleByLine" Hidden="TRUE" />

            <RemoveFieldRef ID="{d3429cc9-adc4-439b-84a8-5679070f84cb}" Name="ArticleByLine" />

Shrinking the SharePoint Log FIle (for dev machines)

Found some useful information on taming a large log file - useful on a SharePoint development machine.

To shrink log files in sql server 2008, first change the recovery model of database to simple, then shrink the log file and finally change back to the previous recovery model. Here is the SQL:

USE dbname;

GO

-- Truncate the log by changing the database recovery model to SIMPLE.

ALTER DATABASE dbname

SET RECOVERY SIMPLE;

GO

-- Shrink the truncated log file to 1 MB.

DBCC SHRINKFILE (2, 1); -- here 2 is the file ID for trasaction log file,you can also mention the log file name (dbname_log)

GO

-- Reset the database recovery model.

ALTER DATABASE dbname

SET RECOVERY FULL;

GO

 

Thanks to an answer by RTTAdmin on the MSDN forums for that suggestion.

SharePoint 2010 Timer Job Journey of Discovery - Updating Web App Properties

So there I was, creating a SharePoint 2010 Timer Job to retrieve and aggregate tag information from the Social Data Service. Using a pattern that worked well in SharePoint 2007, the feature receiver in the solution was tailored to save information for each execution of the job to the property bag of the web application.
But the timer job failed to register when activating this solution through the features admin page on the site. The event log showed an "Access denied" SecurityException error, occuring in the call to SPWebApplication.Update(). The code was simply attempting to set a web application property at that stage.

Time passes... Lots of experimentation and research.... Finally discovered the cause is related to applying least privileges access to accounts on the server install. The account under which the feature gets activated when clicking on "Activate" in the browser UI does not have sufficient rights to make changes in the configuration database. And web application property bag settings seem to be saved to the configuration database rather than to a content database (makes sense, I guess, as a web app can be associated with multiple content databases).

The solution therefore is to activate the feature using PowerShell whilst logged in with an account having update rights on the config database - for instance, using the setup account (which you used during installation, of course, didn't you?!)

Secure Store Application Error 8306

After much experimenting on the SharePoint 2010 server, following tips on the "Claims to Windows Tokens Service" and the settings of the SecurityTokenServiceApplication web service site, finally found that the 8306 error being frequently logged was due to Forms Authentication being enabled in the SecurityTokenServiceApplication web service site. Disabling Forms Authentication removed the issue on the Secure Store Service Application management page in Central Admin

To check this setting, open IIS Admin, browse in the left-hand pane to Sites > SharePoint Web Services > SecurityTokenService Application, and in the IIS section in the right-hand pane open the "Authentication" settings. Only "Anonymous Authentication" and "Windows Authentication" should be enabled.

The 8306 error in the event log was : "An exception occurred when trying to issue security tokens". Thanks to the threads at http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/49508c3a-e44b-4b3a-ad94-0e9957b9e025/ and http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/580a6e7a-e26e-47aa-a6d8-51563b7d27de/ for the final bit of assistance in tracing this one.