Setting up a development environment for SharePoint is relatively straight forward when it comes to on premise solutions. Everything is running on the same server and normally on one IIS website.
Moving to a hybrid model, be that either SharePoint or Provider hosted requires some extra configuration. More so for provider-hosted as you need to configure DNS entries. Specifically, you’ll need to define domains for:
Standard DNS entry and certificate
Forward lookup zone entry for hosting provider-hosted add-ins
Wilcard alias (CNAME). Each add-in when activated provisions a unique DNS domain name. Wildcard Canonical Name is required to support this.
For a development environment, adding DNS entries mat not be possible depending on how much access you have to fully administer the server. It’s also unnecessary for writing and testing add-ins locally. Other users, tester, etc., should not be accessing your development server for testing. That’s what UA environments are for, so it may be easier to bypass this configuration and setup the dev server to work without DNS entries.
It’s been a while and that’s an understatement!! I really do need to get back into the habit of blogging more about my experiences and sharing my knowledge of SharePoint and the related technologies.
I recently decided to sit some exams and go for the MCSD SharePoint Applications, which is comprised of four exams. Seeing as I was going for that I thought it best to also go for the App Builder (previously called Web Applications) which required the first two exams of the SharePoint track plus one for WCF. Happy to report that I passed all five exams and am now certified for both SharePoint Applications and App Builder 🙂
Some code to add the ECB menu to the specified columns of a view:
public void SetEcbColumnOnView(SPView view, List internalNames)
if (view == null)
throw new ArgumentNullException("view");
const string ListItemMenu = "ListItemMenu";
const string ViewFields = "ViewFields";
const string AttributeName = "Name";
XElement root = XElement.Parse(view.GetViewXml());
// Get all columns that use the ECB menu
IEnumerable fields = from el in root.Elements(ViewFields).DescendantNodes().OfType()
where el.Attribute(ListItemMenu) != null
// Remove the ECB Menu from all columns that currently use it.
foreach (XElement el in fields)
if (internalNames.Count > 0)
//Get the field specified in the parameters
fields = from el in root.Elements(ViewFields).DescendantNodes().OfType()
let nameAttribute = el.Attribute(AttributeName)
where nameAttribute != null && internalNames.Any(v => v.Equals(nameAttribute.Value))
// Add the attribute to the columns to show the ECB menu
foreach (XElement el in fields)
var attribute = new XAttribute(ListItemMenu, bool.TrueString);
// Update the view
string viewXml = root.ToString(SaveOptions.DisableFormatting);
Code should be pretty self explanatory, happy coding! 🙂
Thought I’d share a class I use for performance monitoring to help identify areas of code that are causing bottlenecks or take a lengthy time to execute.
In SharePoint we can use the SPMonitoredScope class to wrap areas of code that we want to be monitored.
using (new SPMonitoredScope("SharePoint Performance"))
// SharePoint related code
This will output performance logging statistics to the developer dashboard (if enabled) and to the ULS.
For general SharePoint performance logging, SPMonitoredScope is ideal but it only logs methods calls to the SharePoint databases. The class I developed allows you to monitor any method, whether it’s SharePoint related or not.
Areas you might use the custom performance monitoring class would include calls to a custom database, web services or any potentially long running method calls.