GrinGod [dot] Com

I know it’s been a while since I last posted but this is going to be short and sweet.  I’ve just been working on a SharePoint 2010 site where I’ve need to change the names of site content types and have the changes pushed down to a list that already uses the content types.

The content types are deployed using a solution but that’s where the automation ends.  However, this is where Powershell steps up to the mark.  With Powershell we can quickly automate just about anything in SharePoint.

Here’s the script I can up with:

$web = Get-SPWeb http://www.example.com
$list = $web.Lists["TargetList"]
$list.ContentTypes | ForEach {
    $_.Name = $_.Parent.Name
    $_.Update()
}

Today I tried migrating a Visual Studio WPSBuilder project from one machine to another.  The originating machine was 32bit Windows Server 2008 the destination machine was 32bit Windows Sever 2003 Standard.

To migrate the project I simply zipped the solution folder and copied it across to the destination machine, unzipped and opened in Visual Studio.

However, when I came to build the SharePoint solution file using the Tools -> WPSBuilder -> Build WSP, I got the following error in the output window:
“Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection”

When Googling the the error message the only result was on the WSP Builder CodePlex site and was about 64bit versions of the Cablib.dll assembly.  As neither of my machines is 64bit I figured this wasn’t the issue.

I’m not sure exactly what was causing the problem but this was the solution:

• Open the project folder in Explorer
  • Delete the bin folder
  • Delete the obj folder
  • Delete the wsp file in the project folder.
• Re-open the project in Visual Studio
  • Compile the project
  • Build the WSP (Tools -> WPSBuilder -> Build WSP)

After this everything was back to normal.

Background:

For work, I’m using a Windows 2008 Server virtual machine for doing all my SharePoint and .Net development on.  As it has got all of the cool stuff I’m working on, it is also the machine that I use to demo what I can do to clients.  Recently I’ve had a bit of a serge in the number of clients wanting to see Nintex Workflow 2007 (NFW2007) for SharePoint.

One of the cool features of NWF2007 is the whole Lazy Approval system, whereby users don’t have to go into SharePoint to approve to decline requests, they can just reply to the notification email with “approved”, “declined”, “ok”, “yes”, “no” or any other recognised word as the first line of the email.  In or to demonstrate this I need to setup and email system on my local machine.  The SMTP (sending) side of things is easy as it is built in to Windows 2008.  However, POP3 is a bit of a problem.  Previous version of IIS had a simple POP3 service but that has been dropped in IIS7.  The Microsoft way would be to install Exchange Server but that is a little too heavyweight for what I am trying to acheive.  Luckily a company called Visendo provides a free solution to plug the gap.  So now I can demo Nintex notification features.

Another feature I also wanted to demonstrate was setting up Active Directory accounts and then using those new accounts.  Nintex has got actions that allow you to interact with Active Directory but to then do anything usefull with the account required modifying xml config files and restarting the Visendo service.  But Nintex can call web services, so I’ve created a web service that has an AddAccount and DeleteAccount methods to update the Visendo configuration and restart the service.

Download:

I’ve made the source code for this web service freely available should anyone else want to have this sort of functionality: VisendoSMTPService.  The code is written against .Net 3.5 and is provided “as is” with no sort of warranty and is most definitely NOT recommended for live systems.  The code is released under a BSD License.

As part of a Microsoft Dynamics CRM customisation project, I was recently tasked with modifying an ISV add-in page so that individual sections of the page could be refreshed without having to refresh the entire page.

That in itself was nice and easy, it just required the use of a couple of UpdatePanel and UpdateProgress controls to be dropped on the page along with a ScriptManager control to handle the partial postback requests.

However, there were a couple of gotchas that I didn’t foresee.  Along with the partial updates, the client wanted the parts of the page to load the first time after the page had first loaded in the following order:

1. Load base page.
2. Start load of Application Status section.
3. Start load of Risk section.
4. Start load of Alerts section.

Unfortunately, the ScriptManager that comes with ASP.Net AJAX only handles one postback at a time.  Any subsequent postbacks take precedence over earlier request, which is fine if you only have one update panel on a page but this initially resulted in only the Alerts section being loaded – the other postbacks being canceled.

Luckily I found a very useful post on Amit’s Blog: Asp.Net Ajax UpdatePanel Simultaneous Update.  This post provides code that queues postback requests.  Ideally I would have liked to have the requests happening at the same time, but this is the next best thing.

The other problem that I found was that one of the sections on the page had previously been dynamically creating and reqistering script that got loaded and executed when the page loaded using:

Page.ClientScript.RegisterClientScriptBlock(this.GetType(),
    "ShowNavBarItem", script.ToString());

Unfortunately that doesn’t work with the AJAX ScriptManager.  Instead I had to change the code to use the ScriptManager to load and execute the code using the following:

ScriptManager.RegisterClientScriptBlock(updatePanelApplications,
    typeof(UpdatePanel), "showNavBarItems", script.ToString(), true);

This means that each time the section is updated I can re-generate the script and it will be executed again.

With this AJAX loading and some enhancements to the SQL code, users now get a much fasted load and response time for the page as the no longer have to wait for the whole page to be rendered before seeing information appearing on the page.

I’ve been developing with SharePoint for about 9 month now, and by developing I don’t mean airy-fairy SharePoint Designer drag-and-drop, I mean proper getting your hands dirty in code because SharePoint doesn’t have an *cough* out of the box *cough* feature that does what you want.

Mostly, deployment is done in two stages, firstly to a UAT box and then to a Live box.  Obviously the most efficient way to do this is to bundle your features into a solution which can easily be deployed onto any number of machines.  But, it does mean you have to make sure you’ve got everything right.  Untangling mistakes in your code can be a right royal pain in the arse.

By the time you’ve developed your solution, tested it out, deployed it to UAT and tested it again you should be fairly confident that when you come to deploy it on the Live server things should go pretty smoothly.  And, touch wood, to date things have gone smoothly.

But I still can’t get over that rush of adrenaline that comes with clicking “Activate Feature” after deploying the solution on Live.  In the second or two whilst the page waits to reload my mind runs through all the possible things that could go wrong and how long it would take me to unpick the changes my code might have got half way though.  Then the page finally loads…..

….. “Feature Activated”, phew!  Time for a lie down to clam my nerves.

Last year I was working with a client to develop some ISV add-ins for Microsoft Dynamics CRM.  Recently I was alerted to the fact that one of them – a seperate aspx page that loads in an iFrame on the account details panel – wasn’t printing correctly.

It displayed correctly in the normal view form, appeared correctly on the print preview form but when actually printed it was collapsed down to one or two pixels high.

After doing a bit of research, I found this post by Vince Bullinger, in which he gets around the problem by, as far as I can tell, modifying a core CRM css file.  Whilst this will work, it should be noted that any modification to core CRM files is not supported and will almost certainly break or be lost by updates and hotfixes.

Another problem with the code Vince Bullinger gives is that the iFrames a fixed height and that applies to ALL ISV iFrames.  However, with this knowledge I was able to  come up with my own solution that uses a bit of Javascript to ensure that iFrames are printed and at the correct height to display all the content:

<%@ Page Language="C#" AutoEventWireup="true"
    CodeBehind="Summary.aspx.cs" Inherits="CRMWeb.SummaryStatus.Summary" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Summary Status</title>
    <style type="text/css">
        #pageWrapper
        {
            position: absolute;
            top: 0;
            left: 0;
        }
    </style>
</head>
<body>
    <div id="pageWrapper">
    <form id="form1" runat="server">
        <!-- content goes here -->
    </form>
    </div>
    <script language="javascript" type="text/javascript">
        var dh = document.getElementById("pageWrapper").offsetHeight;
        document.parentWindow.frameElement.height = dh;
        document.parentWindow.frameElement.style.display = "block";
        document.parentWindow.frameElement.style.height = dh + "px";
    </script>
</body>
</html>

This solutions requires that you surround the content of your page with a div, in this case <div id=”pageWrapper”></div>.  This is used by the block of Javascript at the end.

The purpose of the Javascript is to use the pageWrapper div to find out the height of the content.  This height is then used to set the height of the iFrame that contains the page and to set the display style of the iFrame to block.

It probably doesn’t require the iFrame height and the iFrames style.height both being set but I decided to take a belts and braces approach.

In addition to ensuring the iFrame content is printed, I am also planning on implementing the code on Vince Bullingers page for loading a specific css stylesheet for printing.

When I first started developing with SharePoint in June last year the last thing that was on my mind was Enterprise Search.  I had considered it the sort of technology that you just plug in a magic box and it just did all the work for you.

Recently, however, I have been involved in developing a customised search solution using Microsoft Office SharePoint Server (MOSS) to allow a client to search client and non-client related documentation within their organisation.   What I rapidly discovered is that enterprise search is not a plug-and-play affair.  A lot of thought needs to go into the meta data that is used to define the taxonomy of the data (in this documents) and also how users are going to interact with search and how to make sure they get the information they need.

I have also recently been on a training course at FAST Search,which was acquired by Microsoft in April 2008.  The course was both an introduction to the structure of FAST ESP and also an in-depth look into customising the internal, both feeding content into the indexing engine of FAST ESP and building a rich user experience for getting content from the FATS ESP search engine.

The two activities have really awaken me to how powerfull enterprise search can be in empowering users to find information which previously they either may not have know how to access or, more likely, simply hadn’t known existed.  Whilst I was learning about FAST Search, it was generally anticipated that it would be included with the next generation of MOSS.  Today that was confirmed at FASTForward ’09 when Microsoft announced its roadmap for enterprise search which has two initial streams, firstly FAST Search for Internet Business which is mainly aimed at internet retail businesses – like you’d use to find products on Amazon.  The second, and more interesting for me, stream is FAST Search for SharePoint, which will integrate FAST Search more closely with SharePoint and would be used for the type of internal information discovery that I have been working on recently.

Mark Harrisson also noted on his blog that Microsoft is going to be offering ESP for SharePoint immediately which is

a special offering that allows customers to purchase high-end search capabilities today, with a defined licensing path to FAST Search for SharePoint when it becomes available.

I haven’t been able to find out more information about ESP for SharePoint, but it certainly looks like it could be an interesting product to get hold of.  I the mean time I’m keen to continue working with MOSS Enterprise Search and have just the right project lined up to flex my new found love of search on.

As well as starting to work with SharePoint in the last two months, I’ve also been doing some development in Dynamics CRM4.  In the past week I’ve been porting an ISV add-on that was written for CRM3.  Whilst most of the code is pretty much the same, there are a few gotcha to watch out for.

The first problem I came across was the web-service authentication.  I’m not a CRM expert but I believe this has something to do with the new multi-tenancy installation option.  Now when you connect to a web service you need to create a CrmAuthenticationToken and pass it to the web service.  This allows you to specify which organisation you are connecting to.

Once connected to I started getting the following error when running a FetchXML query:

<error>
  <code>0x8004111a</code>
  <description>An aggregate operation was initially specified, but no aggregate operator was encountered.</description>
  <type>Platform</type>
</error>

This error was being generated by the following FetchXML query:

<fetch mapping="logical" aggregate="true">
   <entity name="account">
      <filter>
         <condition attribute="accountid" operator="eq" value="edd2b749-9f58-dd11-90aa-00155d0a0e03" />
      </filter>
      <link-entity name="contact" from="accountid" to="accountid">
         <attribute name="contactid" aggregate="count" alias="myCount" />
      </link-entity>
   </entity>
</fetch>

The purpose of this query is to count all the contacts that are linked with a specific account.  It does this selecting an account entity with a specific id and then counting all the contact id’s for the contacts that are linked to the account.

For some reason the xml parser finds the aggregate=”true” flag but doesn’t find the count aggregate on the linked entity.  Quite why this works in CRM3 but not in CRM4 is beyond me but what I do know is that turning this query around works:

<fetch mapping="logical" aggregate="true">
   <entity name="contact">
      <attribute name="contactid" aggregate="count" alias="count" />
      <link-entity name="account" from="accountid" to="accountid">
         <filter>
            <condition attribute="accountid" operator="eq" value="edd2b749-9f58-dd11-90aa-00155d0a0e03" />
         </filter>
      </link-entity>
   </entity>
</fetch>

In this case the query is run against contract and the id’s are counted where they are linked to a specific account.  I assume this works because the aggregate attribute is on the root entity.  I haven’t tested if it is possible to add more aggregates to the link entities or not.

This morning I ran into a problem when running a repair on my broken SharePoint installation.  Everything seemed to be going well until the setup needed to restart the World Wide Web Publishing service (IIS).  The error message was rather cryptic, say that it might be due to my login account not having service start permissions – but I know I have.

Debugging step 1:  Look in the windows services list and see if I can manually start the service. This was a little more helpful as it told me it couldn’t start due to a dependency not starting.

Debugging step 2: Check the service dependencies.  It appears that the Windows Process Activation service (WAS) wouldn’t start, although it only returned the message “Error 13: The data is invalid�?.

Debugging Step 3: Check the system event log.  Here I found the most helpful message so far:

The Windows Process Activation Service encountered an error trying to read configuration data from file ‘\\?\C:\Windows\system32\inetsrv\config\applicationHost.config’, line number ’0′.  The error message is: ‘Configuration file is not well-formed XML’.  The data field contains the error number.

It seems that at some point the applicationHost.config got trashed.  Luckily, when you make changes to web applications in IIS it creates a backup of the applicationHost.config file in c:\inetpub\history.  All you need to do is copy a good copy from the history and put it into c:\windows\system32\inetsrv\config.

And Roberts your mothers brother, WAS starts, IIS starts and the repair of SharePoint can continue!

ps. I’m running IIS7 on Windows 2008 Server.

I have just leant the hard way that you should always check the name you have given your feature before deploying it to a server.

Quite stupidly I created several features, at least two of which I now know conflicted with existing SharePoint features.  I used the xcopy method of deploying the feature on my local dev machine with the “/Y�? switch to suppress prompts when over-writing existing files, so at the time I didn’t realise what I had done.

It was only when I can to create a new site collection that everything call falling down.  I’m currently downloading the SharePoint installation DVD from Microsoft in the hopes that a re-install will fix the problems.

From now on I’m going to be prefixing all features I create with the clients name.  This will provide two benefits:

1. It will greatly reduce the risk of a feature name conflict.
2. It will group all the directories together in explorer for easier deletion.