SharePoint and Extension methods… super cool

I must admit that Extension methods in C# has got to be one of the coolest ideas ever for the language, for one huge reason.  They allow intelli-sense to automatically expose the methods as if they were part of the original class.  This opened up a huge opportunity for simplifying complex tasks into easily reusable bite that were automatically available once the containing assembly was referenced.  Now granted, this isn’t much different from writing custom library of methods to wrap all the heavy lifting, but extension methods put them right in front of you without needing to look them up, and that means people can’t help but use them… that’s cool.  This mean a more natural reuse of existing code, and that means more code usage which should help testing and code coverage.

Now, along comes SharePoint, a prime example of something hideously beautiful… even with all the new things added over the years its still at its heart a big customizable list manager, which lets you granularly control and render the types and views of the data in each list.  Unfortunately, like anything technology based… the simpler it is for the end user, the more complex it is for the engineers.  It’s like a self parking car… a $1 button on your dashboard probably equates to a life time of engineering and billions in R&D if you trace the evolution of all the tech involved.

SharePoint offers lots of control through a very extensive server side object model (there are also client side object models but that’s not the focus here), and everything is linked together in a nice parent child relationship of objects.  This is great for understanding the inner workings of everything, but day to day, and especially for code maintenance and robustness, its a bit of a pain.  Two of the biggest pain points were security changes (not uncommon to be a pain), and setting the data of a specific list item field (its simple to do, but just as simple in what it does).

Starting with the security activities; these were one of the most obvious to implement as an extension method since there are multiple securable objects in SharePoint.  With a couple overloads tagged as extensions, I took the logic of adding for example down from finding the user by login name, checking if an role association already existed, and if not, finding the role definitions and then the particular role definition by name, creating a role association and then adding it and updating the securable, and turned it into a single call on and SPWebs and SPLists that takes a login name and role names as strings.  This mean that even both long time and recently hired developers writing code to manipulate the security in SharePoint simply had to call spWeb.AddMemberWithRole(“someuser”, “somerole”)… it just showed up for everyone to use; far easier.  Because it was so easy to use without looking for the methods, people weren’t rewriting new version, we just used what appeared as method of SPWeb and SPList objects.  This included demo data imports and data migrations, which meant the same block of code was easily reused and easily tested everywhere under tons of edge cases.

So I realize that by passing in two strings, means that we are not able to reuse references to underlying objects that we have already found when previously calling this method, and this is true, but given that where we used these, adding one user at a time in a stateless web environment, we usually started with string data for each request anyway.  We also could string together the logic of the larger extension method into smaller extension methods on each object, with things like FindOrCreateRoleAssociation, and such, covering all our needs but so far the need hasn’t come up and its been over three years.

Now, for the most powerful extension method in the arsenal, setting the field values on items.  This extension method is probably the most used and there is a reason for it.  Out of the box, SharePoint provides a simple indexed method for setting a field value in a list item, and it works ‘fine’ for most field types… the problem is that as simple as it is, it behaves just as simple.  It doesn’t do any thinking for us, which means you need to tell it exactly what to do.  It works fine for string and number typed fields, but once you start to deal with lookups and taxonomy fields, it requires a lot of help.  I am not going to go into specifics due to confidentiality, but essentially, this easy to access extension method provides two things that SharePoint doesn’t.

First, we would pass in an object type and try to figure out how it fits based on the field type we are setting.  For example, if you enter a “123;#Hello World” for a lookup field, or a SPFieldUserValue for a user field, we would let SharePoint handle it, but if you just entered “Hello World” it could use the information available with that Field type to figure out exactly what SharePoint needs for a fully qualified value.  By providing support for Lookups, Users, DateTime (with safe range checking), and Taxonomy fields (even supporting navigating term store paths), we were able to use this method for copying data in all our event receivers, custom input screens, and all of our data migration/importing (which means that we can provide highly adaptive importing reducing migration efforts).  This means that the same consistent data type handling use used everywhere, and after a lot of edge case handling, is far smarter and adaptive than SharePoint out of the box.

The second thing it does that SharePoint doesn’t do, is provide feedback about whether it actually preformed a change.  The method, tells us if it actually made a change, so that we can track our ‘sets’ and then only perform a SPItem.Update if we actually made a change.  Why is this important? Well, even though SharePoint has the raw data, it doesn’t detect if changes actually occurred, and that means that event receivers will always fire even if no changes occurred and AfterProperties are always set for any fields touched.  By tracking field changes ourselves and only saving when required, we are able to reduce the execution of event receivers to a minimum improving performance on saves.

As usual, none of these methods themselves are special, but the use of them as extension methods with a descriptive method name means that anyone working on the code can and will use it, improving custom code reuse, and reducing the number of replicated methods and helping new developer training.  Some of the hundreds of extension methods we use, like those couple mentioned becomes so natural to call that when working on something new performing doing basic SharePoint tasks you start typing the method names out of habit, forgetting that they aren’t yet there out of the box.

Visual Studio .Net 2013 – Login fails with error “Browser is security restricted or JavaScript is disabled”

After installing Visual Studio .Net 2013 onto a Windows Server 2012 system for doing SharePoint 2013 development, I found I was unable to login with my MSDN profile to Visual Studio.  Instead I received a cryptic and unhelpful error message “Browser is security restricted or JavaScript is disabled”.  I searched the web a little and found assorted solutions which seemed to have assorted results, and finally I found that the problem went away when I turned off “IE Enhanced Security Configuration” from the Server Manager.  I was able to then restart Visual Studio and log in with out a problem.

I actually found this as a solution for a number of times when I was having issues activating Microsoft Office 2013 also.

Errors importing SharePoint web parts and Health Monitor alerts

This is a draft, but to get the notes down I am publishing it and will update it master with the details.

We had been receiving errors alerts in the Health Monitor after upgrading NeoStream’s P4E product line to SharePoint 2013. Although the error alerts were front and center in the monitor. It wasn’t breaking anything so we ignored them.

I recently started mucking around with importing sites from PowerShell and cane across some errors that had the same smell about them.

These errors seemed situational at first, occurring for a while and then disappearing. It turns out that the error “failed to import unknown web part”, which would last for a while in PowerShell then go away, would actually go away the moment I opened a specific SharePoint web part page in the browser. Something was amiss and sharepoint corrected it when the page opened.

I ran a couple scripts to diagnose the web parts in error and nailed it down to a custom web part in the product. This webpart was pretty benign itself, and after checking that it wasn’t the configuration of the web part I cracked open the code.

The answer was immediately apparent…

Something that alot of people don’t know is that sharepoint operates in a few different processes, including the IIS worker process, the SharePoint Timer service, and (when you use PowerShell) in PowerShell. Well of these processes and more, only one of them actually has a SPContext.Current, which is created in the ASP.Net pipeline based on the http request. This means that any code calling methods or properties on the SPContext.Current which is outside of ASP.Net, will fail with an object ref error.

So what’s that got to do with web parts since they are UI and wouldn’t need to be loaded outside of the website? Well SharePoint tries to validate the registered web parts (reporting the results in the monitor) and configure the web parts when importing via PowerShell. These processes require loading the data, which sharepoint uses the binary serializer for, which actually creates an instance of an object. Now it doesn’t raise any control lifecycle events which would make up most of the code but it does call the parameter less constructor and initialize any fields.

So if you have any code called from the constructor that calls SPContext.Current, that doesn’t check for it to be null then and exception will occur during deserializing. This exception will also occur if you initialize any fields from SPContext.Current, which was the cause in this case with:

private SPWeb spWeb = SPContext.Current.Web;

So making that a read only property, solved that as those aren’t touched by the serializer.

Packaging and Deployment – ‘missing types’ compiler errors using Visual Studio 2012 and SharePoint 2010 tools

For a while now, the team and I have been dealing with a odd behavior in Visual Studio 2012 and SharePoint 2010, disruptive to the point that I actually scripted out the whole build and packaging process from the command line just to package up our WSPs (SharePoint packages).  Basically it happened like this… we has a solution with a combination of Class Library projects and SharePoint projects, and were able to compile the projects individually or as a solution in Visual Studio, but when trying to package or deploy them to SharePoint via Visual Studio we would receive a variety of errors about missing types.  These missing types were all part of the class projects that were referenced by the SharePoint projects, providing a variety of utility classes and such, which all compiled fine when simply doing a build, but were reported as missing when we attempted to create SharePoint packages.

Well with no useful information from Visual Studio, the issue just sat on the side lines until either time or frustration found me.  The fact that we could compile from the command line using MSBUILD only added to the confusion, but gave us an opportunity to ignore the issue as long as possible.  But alas, all good things must come to an end, and I found myself in a situation where I needed to actually deploy from within Visual Studio, and so I looked again at the issue.

Well with a bit of speculation, and some criticism of the SharePoint tools for Visual Studio, here’s what seemed to be going on.  The SharePoint project templates and tools are designed for moving forward, and are not friendly to changes or reworking.  This is obvious in the management of features and packages, with the unfriendly two column UI for adding and removing items.  An important thing in SharePoint packages is sequence, however only one of the many item list in the SharePoint tool UIs provides buttons for reordering and unfortunately this is not the one.  In the case of this issue, it appears to be the package additional assemblies.  As time went by and code was refactored and moved to enhance reuse and organization, more project assemblies were added to the various packages.  However, the sequence of the assemblies isn’t easy to manipulate and can intermittently cause issues packaging issues when code a lower level project is changed, as the project additional assemblies appear to be recompiled during packaging either in a weird order or with weird references.

Without spending an inordinate amount of time looking into exactly why, what seemed to help mitigate the issue, was to open the package files in notepad and reorder the additional assemblies such that they would be added in the same order that they would naturally be compiled.  This seemed to clear up the issue, allowing to the SharePoint package projects to be published and deployed again.

So the lesson here would seem to be, make sure you monitor and reorder your package additional assemblies…

Feature contents is another one to watch for order, but that’s a different story.

Using Find and Replace in Visual Studio .Net with Regular Expressions to Bulk Change Properties and Methods (or anything else)

This is a really quick sample of using Regular Expression in Visual Studio .Net to perform and intelligent Find and Replace.  Documented mainly so I don?t forget it.

The need for this arose when I was extracting properties from a class, so that the data of the class was separate from the functionality.

Unlike normal regular expressions, Visual Studio doesn?t let you reference groups derived in the expression, instead a different syntax is used as {?} to tag parts of the string, and then in your replacement expression you refer to those tagged parts by \n (0 being everything, and then 1, 2, 3, etc for the individual tagged parts).

Find

public {[A-Za-z\<\>\[\]]*} {[A-Za-z]*} \{ get\; private set\; \}

Replace With

public \1 \2 \{ get \{ return someClass\.\2\; \} private set \{ someClass.\2 \= value\; \} \}

Note* Be sure to check ?Use: Regular expressions? in the Find and Replace dialog box.

For more details see: http://msdn.microsoft.com/en-us/library/2k3te2cs(VS.80).aspx