After applying SP1 to a SharePoint 2010 farm we found we were unable to run any macros in an Access Services site, it gave a –4002 error. We had seen this error in the past, but the solutions that worked then did not help. As this site was critical, as a workaround, we moved the site to a non-patched SP2010 instance. This was done via a quick site collection backup and restore process. This allowed us to dig into the problem at our leisure.
Eventually we fixed the problem by deleting and recreating the Access Services application within SharePoint on the patched farm. We assume some property was changed/corrupted/deleted in the application of the service pack.
So we now had a working patched farm, but also a duplicate of Access Services site with changed data. We could not just backup and restore this as other sites in the collection had also changed. Turns out getting this data back onto the production farm took a bit of work, more than we expected. This is the process we used
- Open the Access Services site in a browser on the duplicate server
- Select the open in Access option, we used Access 2010, which it had originally been created in
- When Access had opened the site, use the ‘save as’ option to save a local copy of the DB. We now had a disconnected local copy on a PC. We thought we could just re-publish this, how wrong we were.
- We ran the web compatibility checker expecting no errors, but it reported a couple of them. In one form and one query extra column references had been added that referenced the auto created SharePoint library columns (date and id stamps basically) These had to be deleted by hand.
- We then could publish back to the production server
- We watched as the structure and data was publish
- Then it errored. On checking the log we saw that it claimed a lookup reference had invalid data (though we could not see offending rows and it was working OK). Luckily the table in question contained temporary data we could just delete, so we tried to publish again
- Then it errored .On checking the logs again we saw it reported it could not copy to http://127.0.0.1 – No idea why it looking for localhost! Interestingly if we tried to publish back to another site URL on the non-patched server it work! Very strange
- On a whim I repeated this whole process but using Access 2013 RC, and strangely it worked
So I now had my Access Services site re-published and fully working on a patched farm. That was all a bit too complex for my tastes
I recently posted on how you could use the new fakes tools in VS11 to fake out SharePoint for testing purposes. I received comments on how I could make my Shim logic easier to read so though I would revisit the post. This led me down a bit of a complex trail, and to Pete Provost for pointing the way out!
When I did the previous post I had used SP2007, this was because I was comparing using Microsoft Fakes with a similar sample I had written ages ago for Typemock Isolator. There was no real plan to this choice, it was just what had to hand at the time. This time I decided to use SP2010, this was the process used that actually worked (more on my mistakes later) …
- Using a Windows 7 PC that did not have SP2010 installed, I created a new C# Class Library project in VS11 Beta
- I added a reference to Microsoft.SharePoint.DLL (this was referenced from a local folder that contained all the DLLs from the SP2010 14 hive and also the GAC)
- THIS IS THE IMPORTANT BIT – I changed the project to target .NET 4.0 not the default 4.5. Now, I could have changed to .NET 3.5 which is what SP2010 targets, but this would mean I could not use MSTest as, since VS2010, this has targeted .NET 4.0. I could of course have changed to another testing framework that can target .NET 3.5, such as nUnit, as discussed in my previous post in the VS11 test Runner.
- You can now right click on the Microsoft.SharePoint.DLL reference and ‘add fakes assembly’. A warning here, adding this reference is a bit slow, it took well over a minute on my PC. If you look in the VS Output windows you see a message the process is starting then nothing until it finishes, be patient, you only have to do it once! I understand that you can edit the .fakes XML file to reduce the scope of what is faked, this might help reduce the generation time. I have not experimented here yet.
- You should now see a new reference to the Microsoft.SharePoint.220.127.116.11.Fakes.DLL. and you can start to write your tests
So why did I get lost? Well before I changed the targeted framework, I had tried to keep adding extra references to DLLs that were referenced by the DLL I was trying to fake, just as mentioned in my previous post. This went on and on adding many SharePoint and supporting DLLs, and I still ended up with errors and no Microsoft.SharePoint.18.104.22.168.Fakes.DLL. In fact this is a really bad way to try to get out of the problem as it does not help and you get strange warnings and errors about failures in faking the are not important or relevant e.g.
“\ShimTest\obj\Debug\Fakes\msp\f.csproj" (default target) (1) ->1> (CoreCompile target) –> “\ShimTest\f.cs (279923,32): error CS0544: ‘Microsoft.SharePoint.ApplicationPages.WebControls.Fakes.StubAjaxCalendarView.ItemType': cannot override because ‘Microsoft.SharePoint.WebControls.SPCalendarBase.ItemType’ is not a property
The key here is that you must be targeting a framework that the thing your are trying to fake targets. For SP2010 this should really be .NET 3.5 but you seem to get away .NET 4.0 but 4.5 is certainly a step too far. If you have the wrong framework you can end up in this chain of added dependency references that you don’t need and are confusing at best and maybe causing the errors nor fixing them. In my case it seem a reference to Microsoft.SharePoint.Library.DLL stops everything working, even if you then switch to the correct framework. When all is working you don’t need to add the dependant references this is all resolved behind the scenes, not by me adding then explicitly.
So once I had my new clean project, with the correct framework targeted and just the right assemblies referenced and faked I could write my tests, so now to experiment a bit more.
I have just published updated documentation on the SharePoint build activity for the Community TFS build extensions.