Wednesday, December 15, 2010

Unable to load DLL 'FileTracker.dll' error in Visual Studio 2010

I got this error, when I tried to build a project in Visual Studio 2010 (professional).
System.DllNotFoundException: Unable to load DLL 'FileTracker.dll': The specified module could not be found.
This build error occurred only in projects in which resource files were used.

Resolution:
1) Open "Microsoft.Common.targets" file located at "C:\Windows\Microsoft.NET\Framework\v4.0.30128".
2) Locate the following line "<TrackFileAccess Condition="'$(TrackFileAccess)' == ''">true</TrackFileAccess>"
3) Change the value to "false"
4) Do the same for the file found in "Framework64" folder also.

Note:
If we have to get rid of this problem in all the machines where it would be deployed, we can edit the ".csproj" file of our project, to include the following lines:


<PropertyGroup>
      <TrackFileAccess>false</TrackFileAccess>
</PropertyGroup>



Make sure that this is at the the bottom of the file just before the closing project tag (</Project>).
Doing so, will however slow down the build time, during deployment.


SharePoint 2010 installation on Windows 7 - Product Config Wizard fails in step 2 with System.FormatException

Today I was trying to install SharePoint 2010 enterprise on my Windows 7 laptop. The product configuration wizard was failing with the following error in Step 2 [creating configuration database].


The exception was:

System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).   at System.Guid..ctor(String g)   at Microsoft.SharePoint.Administration.SPFarm.GetInstalledProductIds()
Reason:
The following registry key had an "invalid" value "0" for the registry name {90140000-110D-0000-1000-0000000FF1CE} :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server extensions\14.0\WSS\InstalledProducts
Solution:


This is the key that is used to determine the current edition (Foundation, Standard,Enterprise..) of SharePoint installed. The correct value of this should be:



88BED06D-8C6B-4E62-AB01-546D6005FE97 - For Enterprise trial
D5595F62-449B-4061-B0B2-0CBAD410BB51 - For Enterprise licensed
B2C0B444-3914-4ACB-A0B8-7CF50A8F7AA0 - For Standard trial
3FDFBCC8-B3E4-4482-91FA-122C6432805C - For Standard licensed

Changing this solved the problem.


   

Friday, October 8, 2010

Export and import of list does not move permissions and security

My requirement was to migrate a list with more than 3000 records and many folders from one site collection to another. Both the list and its folders had unique permissions assigned to it.

My first attempt was to save the list as template with data, and to create the list in my target site using the template. The list was migrated along with its data, but permissions on the list were not. The new list was still inheriting permissions from the parent site.
I then tried using the power shell command "export-spweb", since this command had a parameter "-IncludeUserSecurity", which when set, was supposed to move the list along with the permissions. However, this did not work out either. Looks like a bug with the command.

Resolution:

The solution that worked for me was to use a power shell extension cmdlet developed by Gary Lapointe, a Microsoft MVP.

Here are the steps:

1)  Download and deploy the Cmdlet WSP from here http://stsadm.blogspot.com/2009/02/downloads.html

2)  Use the following power shell commands to deploy the extensions:

Add-SPSolution C:\xxxx\Lapointe.SharePoint2010.Automation.wsp
Install-SPSolution -Identity Lapointe.SharePoint2010.Automation.wsp -GACDeployment

3) Once deployed, use the following command to migrate the list with permissions:

copy-splist -sourcelist "http://xxxx/lists/mylistname" -targetweb "http://xxxxxx/mysitename" -IncludeVersions All -IncludeDes
cendants All -IncludeUserSecurity

This worked like a charm!

Thursday, October 7, 2010

Anonymous access, CQWP and picture libraries

I had used a picture library to store the information to be displayed using a content query web part. It worked fine for authenticated users, but failed when the site was configured for anonymous access. The content query web part failed with the following error, when viewed by anonymous users:

Error while executing web part: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.SetDocumentIconUrlAndOnClickString(SPWeb web, DataRow row, String strDefaultItemOpen, Boolean fSetDocIcon, Boolean fSetOnClick, String fileRefColumnRef, String progIdColumnRef, String fsobjTypeColumnRef, String permMaskColumnRef)..


Resolution:

Investigating the method, SetDocumentIconUrlAndOnClickString using reflector, I found this line of code which would result in this exception for anonymous users:

builder.Append(StrJScriptParameter(Convert.ToString(web.CurrentUser.ID, CultureInfo.InvariantCulture), true));

When I was about to override this behavior by code, I found a more elegant non-code solution on the web. The solution was to export the web part and add the following to the commonviewfields property:

<property name="CommonViewFields" type="string">DocumentIconImageUrl;OnClickForWebRendering</property>

This solved the problem.

Tuesday, September 21, 2010

Anonymous access and EditModePanel

Since I was working on a publishing portal, I had to create a lot of page layouts for my content pages. I had used the edit mode panel to control the UI of my pages in edit mode and display mode.

<PublishingWebControls:EditModePanel  runat="server" PageDisplayMode=”Edit”/> to show the page editing fields without CSS in edit mode
and 
<PublishingWebControls:EditModePanel  runat="server" PageDisplayMode=”Display”/> to show the page fields with style sheet references in the browsing mode.

This worked fine, but only till I configured my site for anonymous access. I was expecting the content under  display mode to be visible for anonymous users as well, but that was not the case. Any page content residing in an "EditModePanel" is visible only to authenticated users.

Resolution:
The resolution was to use another control "PublishingWebControls:AuthoringContainer" in addition to the "EditModePanel". The authoring container control has a DisplayAudience property that can be set to either "ReadersOnly" or "AuthorsOnly".

I used the authoring container control as shown below to get around this problem:

<PublishingWebControls:AuthoringContainer DisplayAudience="ReadersOnly" runat="server">
      Content to be shown for anonymous users <no edit mode panel here>
</PublishingWebControls:AuthoringContainer>

Content to be shown for authenticated users within edit mode panel.
<PublishingWebControls:AuthoringContainer DisplayAudience="AuthorsOnly" runat="server">
    <PublishingWebControls:EditModePanel runat="server" PageDisplayMode="Display">
    </PublishingWebControls:EditModePanel>
    <PublishingWebControls:EditModePanel runat="server" PageDisplayMode="Edit">
    </PublishingWebControls:EditModePanel>
</PublishingWebControls:AuthoringContainer>

This solved my problem, but had to compromise on having two additional controls on the page. If you do not want this overhead, another option is to override this "EditModePanel" class behavior by sub classing it. But for me, the above workaround was just fine.