When using SharePoint sometimes you run into a URL with lots of unicode character markup. Here's a good reference so you can figure out what the h%65ck it all means.
I updated my page layouts that I deployed as a feature, but found that I could not overwrite the Layout File. The solution was to add a new page layout and then you would have to associate the new layout with every page on your site that used it. Obviously with a site of any size you'd have a lot of manual work to get this done, so doing it programmatically makes for a much better (and thorough) approach. After you've got your new page layouts, you could do something like this (in your event receiver class): public override void FeatureActivated(SPFeatureReceiverProperties properties) { //replace current page layouts with new page layouts on all pages SPWeb web = SPContext.Current.Web; SwapPageLayout(web, "FullWidthContentWithTitleV1.aspx", "FullWidthContentWithTitleV2.aspx"); } private void SwapPageLayout(SPWeb web, string oldPageLayoutName, string newPageLayoutName) { PublishingWeb pubWeb = PublishingWeb.GetPu...
I was working on a STSDev project which deployed a feature with a feature receiver. I had the feature working without the FeatureReceiver but as soon as I added the FeatureReceiver related attributes to my <Feature> element I got the following error: Failed to create feature receiver object from assembly "Org.Project.Solution, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c632353d405b3209", type "Org.Project.Solution.MyFeature.FeatureReceiver" for feature 6a9b2358-ea4e-486d-a4e4-4f813c52ce88: System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject() After much digging around I discovered that STSDEV's Solution config file refers to a namespace as well as the dll. My FeatureReceiver's namespace was not prefixed with the right namespace So just...
I wanted to run unattended scripts against SharePoint for various governance and content cleanup jobs and found the guidance for this to be a little confusing. I think it's a good idea to limit the access of any script, so I prefer to set up an App per script and use the Sites.Selected permission to limit the sites to which my app has access. Here's the process I used to get it to work: You can register an app in the Azure portal UI, but there's a few steps that must be performed with PowerShell, so I figured just doing it all in Powershell made it consistent. Step 0: Get the right version of PnP.Powershell I also had to use the PnP.PowerShell 2.2.81 nightly build because there was a bug introduced in 2.2.0. If you need to get a specific version you can run Install-Module, but I prefer to use Save-Module with specific version so I can keep different version of PnP.PowerShell around to avoid having my old scripts affected by new modul...
Comments