We started migrating our old SharePoint 2007 sites to SharePoint 2010. It all has been going pretty smoothly, until we found a pesky little problem when creating new subsites:
"One or more field types are not installed properly. Go to the list settings page to delete these fields."
Not much more detail in the ULS logs to describe which field is not installed properly. After some Googling and experimentation the problem was determined to be the changes between SharePoint 2007 and 2010 in the "Relationship List" (http://{siteurl}/Relationships%20List/AllItems.aspx).
Basically to fix the problem, you need to deactivate the SharePoint Server Publishing Infrastructure feature, delete the relationship list and reactivate the SharePoint Server Publishing Infrastructure feature.
The following PowerShell is all you need:
Disable-SPFeature -Identity F6924D36-2FA8-4f0b-B16D-06B7250180FA -Url http://{siteurl}
$site = Get-SPSite -Identity http://{siteurl}
$site.RootWeb.GetList("Relationships List").Delete()
Enable-SPFeature -Identity F6924D36-2FA8-4f0b-B16D-06B7250180FA -Url http://{siteurl}
Friday, October 1, 2010
Wednesday, June 30, 2010
Add Proxy Settings to web.config file of SharePoint with Powershell
I recently needed to modify the default proxy settings in the web.config file of our SharePoint apps. This was done manually to start with, but after many deployments in multiple environments, doing this manually was a chore and often forgotten. I therefore worked on the following PowerShell script that did what we needed.
The following script changes the default proxy settings of:
to:
Sorry about the crappiness of the cut-and-paste, but this might give you enough help to get you going:
The following script changes the default proxy settings of:
<system.net>
<defaultProxy>
<proxy autoDetect="true" />
</defaultProxy>
</system.net>
to:
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy usesystemdefault="False" proxyaddress="http://proxy.address" bypassonlocal="True" />
</defaultProxy>
</system.net>
Sorry about the crappiness of the cut-and-paste, but this might give you enough help to get you going:
function AddWebConfigModification([Microsoft.SharePoint.Administration.SPWebApplication] $webApp=$(throw 'Parameter -webApp is missing!'),
[string] $name=$(throw 'Parameter -name is missing!'),
[string] $path=$(throw 'Parameter -path is missing!'),
[string] $owner=$(throw 'Parameter -owner is missing!'),
[string] $sequence=0,
[Microsoft.SharePoint.Administration.SPWebConfigModification+SPWebConfigModificationType] $modificationType=$(throw 'Parameter -modificationType is missing!'),
[string] $value=$(throw 'Parameter -value is missing!'))
{$modification = New-Object -TypeName "Microsoft.SharePoint.Administration.SPWebConfigModification";
$modification.Name = $name;
$modification.Path = $path;
$modification.Owner = $owner;
$modification.Sequence = $sequence;
$modification.Type = $modificationType;
$modification.Value = $value;
$webApp.WebConfigModifications.Add($modification);
}
function AddProxySettings([string]$url=$(throw 'Parameter -url is missing!'))
{$webApp = GetWebApp($url);
$owner = "GUID_HERE";
$ensureAttribute = [Microsoft.SharePoint.Administration.SPWebConfigModification+SPWebConfigModificationType]::EnsureAttribute;
AddWebConfigModification -webApp $webApp -owner $owner -modificationType $ensureAttribute -path "configuration/system.net/defaultProxy" -name "useDefaultCredentials" -value "true";
AddWebConfigModification -webApp $webApp -owner $owner -modificationType $ensureAttribute -path "configuration/system.net/defaultProxy/proxy" -name "usesystemdefault" -value "False";
AddWebConfigModification -webApp $webApp -owner $owner -modificationType $ensureAttribute -path "configuration/system.net/defaultProxy/proxy" -name "proxyaddress" -value "http://proxy.address";
AddWebConfigModification -webApp $webApp -owner $owner -modificationType $ensureAttribute -path "configuration/system.net/defaultProxy/proxy" -name "bypassonlocal" -value "True";
AddWebConfigModification -webApp $webApp -owner $owner -modificationType $ensureAttribute -path "configuration/system.net/defaultProxy/proxy" -name "autoDetect" -value "True";
[Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplyWebConfigModifications();
}
Tuesday, September 1, 2009
How to update a SharePoint item while retaining the modified by and date information
In my current project I need to move documents from one document library to another with version history and last modified infomation etc. This works great using SPImport and SPExport.
When the document is moved to the new location, I have a further process of modifiying the values of one of the fields. I needed to do this without modifying the Modified or Modified By fields.
Here is how I did it:
BTW. Using Update() creates a new version here. You can not create a new version by using UpdateOverwriteVersion().
When the document is moved to the new location, I have a further process of modifiying the values of one of the fields. I needed to do this without modifying the Modified or Modified By fields.
Here is how I did it:
foreach (SPListItem listItem in list.Items)
{var modifiedBy = listItem[SPBuiltInFieldId.Modified_x0020_By];
var modifiedDate = listItem[SPBuiltInFieldId.Modified];
listItem[_documentTypeFieldName] = GetDocumentType();
listItem[SPBuiltInFieldId.Modified_x0020_By] = modifiedBy; listItem[SPBuiltInFieldId.Modified] = modifiedDate;listItem.Update();
}
BTW. Using Update() creates a new version here. You can not create a new version by using UpdateOverwriteVersion().
Friday, August 21, 2009
Useful code for modifying a Site
I am currently working on a project that needs to support the clients SharePoint implementation. They do everything directly in production, so I have created a site definition to reproduce there site structure. One feature I created to help me with this is basically a web scoped feature that modifies the site with custom changes I want in code (I am a programmer after all!!).
The following code does some interesting stuff:
PS: Sorry GetContentType and GetListByName are my own custom extension methods. There isn't much to them really, just better error handling then using the default SharePoint API methods with square brackets.
PPS: You also need to set the welcome page back to the default in the FeatureDeactivating method:
The following code does some interesting stuff:
- Creates a document library in code
- Sets the document library title, enables versioning and allows content types in the document library
- Finds a site content type and associates it with the document library
- Changes the content type order so it contains just my content type
- Sets the default page of the site to the default view of the document library
- Adds some of my content type fields to the default view
public class ProjectSiteReceiver : SPFeatureReceiver
{private string _documentLibraryTitle = "Project Documents";
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{using (SPWeb web = (SPWeb)properties.Feature.Parent)
{SPListTemplateType templateType = SPListTemplateType.DocumentLibrary;
Guid listId = web.Lists.Add(_documentLibraryTitle, null, templateType);
SPList list = web.Lists[listId];list.Title = _documentLibraryTitle;
list.EnableVersioning = true; list.ContentTypesEnabled = true;list.Update();
SPContentType contentType = web.GetContentType("Project Document");
SPContentType listContentType = list.ContentTypes.Add(contentType);listContentType.Update();
List<SPContentType> contentTypeList = new List<SPContentType>();
contentTypeList.Add(listContentType);
list.RootFolder.UniqueContentTypeOrder = contentTypeList;
list.RootFolder.Update();
SPFolder webFolder = web.RootFolder;webFolder.WelcomePage = list.DefaultView.Url;
webFolder.Update();
SPView view = list.DefaultView; view.ViewFields.Add("Project ID"); view.ViewFields.Add("Project Type");view.Update();
}
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{using (SPWeb web = (SPWeb)properties.Feature.Parent)
{ SPList list = web.GetListByName(_documentLibraryTitle);list.Delete();
}
}
public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{}
public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
{}
}
PS: Sorry GetContentType and GetListByName are my own custom extension methods. There isn't much to them really, just better error handling then using the default SharePoint API methods with square brackets.
PPS: You also need to set the welcome page back to the default in the FeatureDeactivating method:
SPFolder webFolder = web.RootFolder;webFolder.WelcomePage = "default.aspx";webFolder.Update();
Opening SPFile from full file URL
I had to implement a custom search to find documents matching certain criteria. I could easily find a document and retrieve its "Path" (full url). From this URL, I needed to get the associated SPFile object. This took longer then I thought it warranted.
Here is the solution:
Here is the solution:
string fileUrl = dt.Rows[0]["Path"].ToString();
using (SPSite site = new SPSite(fileUrl))
{using (SPWeb web = site.OpenWeb())
{ SPFile file = web.GetFile(fileUrl); if (!file.Exists)throw new ApplicationException("Could not find document");
return file;}
}
Wednesday, August 12, 2009
Sharepoint Assembly Platform
I recently started a project which consisted of a set of assemblies deployed to the GAC. While integrating with a larger application, the assemblies build configuration were modified to build on x86 Platform (32-bit) explicitly. This was done believing that if they were built as 32-bit, both 32-bit and 64-bit applications could use them.
This worked fine in a 32-bit environment. However, when deploying to a 64-bit environment I was getting "file not found" errors. After some looking into the C:\windows\assembly\gac_msil directory on the server I noticed there where multiple directories there:
After some research I discovered that on a 64-bit server, assemblies built as:
Any CPU: go into the gac_msil directory and can be used by either 32-bit or 64-bit processes.
x86: go into the gac32 directory and can only seen and used by 32-bit processes.
x64: go into the gac64 directory and can only be seen and used by 64-bit processes.
My conclusion: leave the build configuration as "Any CPU" !!!!
This worked fine in a 32-bit environment. However, when deploying to a 64-bit environment I was getting "file not found" errors. After some looking into the C:\windows\assembly\gac_msil directory on the server I noticed there where multiple directories there:
- gac_msil
- gac32
- gac64
After some research I discovered that on a 64-bit server, assemblies built as:
Any CPU: go into the gac_msil directory and can be used by either 32-bit or 64-bit processes.
x86: go into the gac32 directory and can only seen and used by 32-bit processes.
x64: go into the gac64 directory and can only be seen and used by 64-bit processes.
My conclusion: leave the build configuration as "Any CPU" !!!!
Monday, August 10, 2009
Unable to move web part
I had an error with not being able to move webparts from in a page. Something like this:

After a bit of research I found the the problem was related to web part zones having a relative position in the CSS. See http://www.sharepointblogs.com/tmt/archive/2007/11/01/CSS-causes-JavaScript-error-while-moving-Web-Parts-in-edit-mode.aspx .
There are a few ways mooted online to fix this problem, but the best solution for me was to set the position of body css element to relative also:
body
{
position:relative;
}
Problem solved...
After a bit of research I found the the problem was related to web part zones having a relative position in the CSS. See http://www.sharepointblogs.com/tmt/archive/2007/11/01/CSS-causes-JavaScript-error-while-moving-Web-Parts-in-edit-mode.aspx .
There are a few ways mooted online to fix this problem, but the best solution for me was to set the position of body css element to relative also:
body
{
position:relative;
}
Problem solved...
Subscribe to:
Posts (Atom)