The Microsoft.SharePoint.Deployment SPImport class fails when calling the ImportNavigationXml method

The Microsoft.SharePoint.Deployment SPImport class fails when calling the ImportNavigationXml method.

This will be triggered whenever a user opens the Navigation page under Site Settings of a SharePoint site and clicks the “OK” button, even without making changes. Any future export and attempt to import the site will fail with a root cause being a SQL exception:

System.Data.SqlException (0x80131904): Invalid length parameter passed to the RIGHT function.

Information indicates that a assumption made in this SQL function causes a negative number to be passed in and an exception occurs.

No combination of navigation settings, including all menu items seems to resolve the issue. It seems to be one of three core navigation nodes being passed in that triggers the exception.

Using SPListItemCollections indexer to get SPListItem returns different/reset item every time appearing to not save changes

While in a hurry to test some code I discovered that calling the following will not actually save your change:

spListItemCollection[0][“Title”] = “Hello World”;

Instead you need to store the SPListItem returned by the first indexer call and then use it to set and update.

var spListItem = spListItemCollection[0];
spListItem[“Title”] = “Hello World”;

This indicates that even though its a property, the indexer is giving you a new or reset instance of the SPListItem everytime you ask for the same index.

Normally I would have refactored this and used a variable from the get go and so I would have never seen this. This just goes to show even the ones that build the framework don’t even follow their own best practices so always assume the worst and store objects in variables first before using them.

Categories: Uncategorized

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.

Drobo Mini and thin Intel Solid State Drives Getting Stuck

2013/09/22 2 comments

So I bought a Drobo Mini and stuck a couple Intel SSDs in it only to learn that the Drobo Mini isn’t compatible with the 520 series… Boo, but what can yah do, its a valid enough reason they don’t work.

So I would then use the drives elsewhere (they are still great drives), but when trying to eject them I found myself in a very frustrating situation. The Intel drives are thinner than usual and so to make them fit, Intel includes a plastic frame attached to the top of the drive. Its enough to make them fit snuggly in a drive bay without adding weight since the frame only wraps the outside edges.

Well the Drobo Mini has an (assuming its needed but still) annoying strip of flexible metal in it that holds the drive snug. Unfortunately it is not as wide as the drive and once loaded drops into the frame on the drive, holding it in place. Holds it snug nicely, however, when trying to remove the drive, this strip of metal prevents the drive from sliding out. I could slid it out enough to disconnect the drive but any further and the frame would hit the metal springy strip and stop.

The Drobo Mini is mini for a reason… Its packed in tight, with barely any space around the drive openings. With the drive part way out I had more room but the only thing flat and long enough to fit was a butter knife (as I cringe again at the thought) but as I could get part of the metal raised out of the way it was wide enough and flexible enough that the other corner stayed down. Two knives were just two hard to maneuver, so I took a break to let my mind process things.

I needed something wider and thin as paper. Nothing came to mind that would be thin enough but strong enough to lift the metal strip. Then it occurred to me that that it only had to be strong enough to not crumple since if wide enough it could ride along the frame and, with the frame supporting it, lift the metal strip up and out of the way of the frame.

I cut a piece of a cereal box out, almost as wide as the drive but twice as long. Slid the cardboard carefully along side the top of the drive and as far back as it would go, and success.

The cardboard held flat and was enough to lift the metal strip up and I was able to remove the drive.

Categories: DIY Tags: , , ,

Issues with .Net Assembly Binding Redirection between .Net 2.0, 3.0 and 3.5 to .Net 4.0 and 4.5 (relating to SharePoint 2010 and 2013)

After about three hours of uncertainty as to why it didn’t work… a last ditch test and a 3am eureka moment converged to the following:

So a bit of backstory… the company I am working for, without going into the sensitive details, was writing a console app that we wanted to work against both SharePoint 2010 and SharePoint 2013.  Well there’s lots of hacky was to do that, including two different code brancehs which then need to be kept in sync or one code branch but doubling up project files and solutions in the folders, one pointing to SP2010 and one at SP2013… We use TFS build services and so any option would work, but most a management nightmares… so on being asked I suggested we use the assembly binding redirection (just like SharePoint itself does for loading webparts from older versions), as it’s the easiest to maintain.

So we tried… and after a good number of hours by another dev, and then by myself also for three hours, so couldn’t figure out why it didn’t work.  It would compile fine, and using the FUSLOGVW.EXE we were able to see the redirect was occuring, but then it wasn’t able to find the SharePoint 2013 assemblies (version 15).  All we had was a cryptic message at the end of the fusion log about “GAC Lookup was unsuccessful”.

So we ended the day with a big WTF?!?!

Well, so about 2 mins after I logged off, I decided to try one more thing and got a build working by changing the target framework to be .Net 4.5… a step forward.  Although this helped for SharePoint 2013 all of a sudden, it stopped working for SharePoint 2010, again complaining about not being able to find SharePoint.  Odd… but it’s something.

Then at 3am in the morning, the EUREKA moment happened… I figured out ‘why’, and then the details to make it all come together. The problem is that .Net 4.0 and above is a different GAC location now (it’s now in the place it should have always been).  If the project is a .Net Framework 3.5 project then it’s looking in the wrong GAC for the SP2013 assemblies (since they are .Net 4.5).  This was the whole reason it didn’t work from the beginning; when compiled to the right target framework, you don’t even need your own the binding redirection entries since SharePoint actually includes the minimum ones as policies in the .Net 4.5 GAC.  Having made the project a .Net 4.5 project it would have worked fine on SP2013 without any config settings as it would have looked in the correct GAC.

There is a catch though that would seem to be SharePoint specific.  SharePoint 2010 actually checks to ensure the app is targetting the ‘supported’ .Net 3.5 framework.  What this means is that to run against SP 2010 the EXE needs to target a .Net v3.5, while to run against SP 2013 it needs to target .Net v4.5 (or v4.0, but v4.5 is better).  The project can reference the SP2010 assemblies and, if targeting to the correct framework, will automatically adapt for the basic Microsoft.SharePoint assembly (there is a ‘but’ here that didn’t affect our specific situation right now).

So the next question is, how do we have one project target two different framework versions… answer, we don’t.  Luckily for us, MSBuild allows us to pass in overriding values for many things, one of which being the TargetFrameworkVersion (and in support of that, the ToolsVersion if needed).  And so we can instead make two build definitions in TFS (or simply two MSBuild commands if you are using some other automated build tool), one that does the default (or we could explicitly target .Net 3.5) and the other that passes additional arguments to MSBuild to explicitly target .Net 4.5. (it might be possible that we could also do one build definition with two outputs, one for each framework also). Now when the builds are kicked off, the exact same code, project file, and solution is used, but the MSBuild overrides the version and gives us one for SP 2010 and one for SP 2013.

Here are the details of the changes to make.  Open the original solution and ensure that it’s targeting .Net 3.5, and that the SharePoint reference is pointing to the SP 2010 (v14) DLL. Create one build defintion to do the defaults, and then a second build definition and add additional MSBuild arguments (in TFS you can also add them per queued build if you wanted to test this first) of:

/tv:4.0 /p:TargetFrameworkVersion=v4.5

* Note, both build defintions would point to the same SharePoint 2010 build server, for the compile to work, and you will also need to ensure that the .net 4.5 is installed to the SharePoint 2010 build server also (this doesn’t affect SharePoint, but is required to pick the 4.5 target when compiling).

Now, when you kick off each build it should create one as a SP 2010 compatible EXE and one as a SP 2013 compatible EXE (if we wanted we could use more arguments to alter the EXE output name to make them distinct also, such as “MyToolForSharePoint2010.exe” and “MyToolForSharePoint2013.exe”).

One code base… one thing to maintain, driven by configuration.


Some useful references:

The time travellers ego…

I was just watching “Back to the Future 3”, and it was at the part where they were discussing the driving their car into the future on track that didn’t yet exist. The explanation was sound at first, sure the track doesn’t exist now but in 100 years it will so we will appear and glide along…

But the earth is rotating, fast, about 1,674.4 km/h it would seem. So maybe you take that into account and travel to the exact same time of day in the future (or past), which the movie might imply by only having a date on the time circuit’s.

But the earth is also moving, fast, about 108,000 km/h through space, orbiting the sun. This means that the earths position in space tomorrow at this same time of day will 2,592,000 km away from where it is now. So only if the orbit of the earth around the sun is perfectly consistent, the best you could do is travel forward by years, so that you appear on the earth as it passes by at the perfect moment and is at the same point in its daily rotation as to pit you at the right spot on the surface.

But there’s more… Just as the earth orbits the sun in our solar system, our solar system orbits in the Milky Way Galaxy. This galactic year, as it’s called, takes anyway from 200 to 250 million earth years. That’s a pretty big margin of error, and even if you got it perfect, you would only be able to travel forward or back in steps of galactic years. That might explain why so many cartoons show people jumping back into the past and landing face to face with a T-Rex.

Now without doing a bunch of research, I would assume based on the various theories of universal expansion and contraction that our galaxy is also moving, either towards, away from, or around some other central point. So this again would mean that the odds of you moving to another moment in time where the train tracks are in the exact same point in the universe are slim to none.

So either ol’ Doc Brown was not only able to move through time but also calculate and reposition the delorean to another point in the universe based on “approximate” measurements at the high end, all while also ensuring that their forward movement was maintained relative to the surface of the earth as it spun and moved through space as though in a huge gyroscope, or… the earth is the center point for all of space time, and so all changes in time would be relative to the earth as a fixed point in space… Talk about thinking you’re the center of the universe.

All that said, it is a great movie.

Categories: Uncategorized Tags: , ,