Displaying a Visio 2010 drawing with links in a Page Viewer Web Part

04 October 2011

If you have tried saving a Visio 2010 drawing as a web page and then displaying it in a Page Viewer web part in SharePoint then you will know that by default hyperlinks in the drawing will no longer work.

This is because the default output format for Visio 2010 drawings being saved as a web page is XAML. When you save the drawing as a web page a collection of files are generated one of which is called xaml_1.js. Opening the Visio drawing .htm file directly in the browser works as expected and hyperlinks are active. However, if you try to display the Visio drawing inside a Page Viewer web part you will see a JavaScript error that references the xaml_1.js file seemingly because there is conflict with DOM elements that exist in the standard SharePoint page.

I suspect that this didn't receive much attention during testing by Microsoft as the assumption could be that if you are using Visio 2010 you will also be using SharePoint 2010 and Visio Services to display your Visio drawings in the browser.

There is a way to work around this by changing the output format of Visio to VML (Vector Markup Language) instead of XAML. Unless you choose VML the first time you save as a web page then Visio remebers the XAML default and there is no setting in Visio (that I can find!) that allows you to change this default. The only option left is to crack open the registry and go searching for the relevant setting.

Open regedit and go to - HKEY_CURRENT_USER -> Software -> Microsoft -> Office -> 14.0 -> Visio -> Solution -> SaveAsWeb -> Settings then change "priformat" from XAML to VML

Save your Visio drawing as a web page again and this time it will be produced using the VML format which does not include the xaml_1.js file that causes the error and prevents links from working.

When you add the link to a Page Viewer you should now have working links.

Most Common SharePoint Application Development Mistake

28 July 2011

SharePoint is a huge product with plenty of opportunities to make mistakes in lots of different ways. The infrastructure could be configured badly, the business may not have clearly defined what they hope to achieve with SharePoint or the information architecture is allowed to sprawl out of control.

Having worked with SharePoint for over 7 years there is one mistake that I see being repeated over and over again when SharePoint is introduced into an organisation.

Imagine the scene, SharePoint has just been installed and in this case the business do have a clear idea of what they expect from SharePoint. The first priority is to move several small legacy systems including some spreadsheets and a couple of Access database applications onto SharePoint.

The justification for this is that moving these apps to the SharePoint platform will make them easier to find and share, they will immediately fall under the SharePoint backup and disaster recovery regimes and using SharePoint as the interface will provide a more consistent user experience across all of these apps. In addition to that the business has heard all about how rapidly small applications can be developed and deployed using SharePoint and are excited to see this process in action.

Back in the IT department the .Net developers have just come back from a weeks intensive training and naturally they want to make a good impression by demonstrating their newly acquired SharePoint knowledge and showing the business what a great platform SharePoint is.

The requirements to migrate several spreadsheet based apps start to roll in and the team begin by putting together a few quick prototypes. The decision is made to move the spreadsheet contents across into SharePoint lists to take advantage of functionality like views and to be able to apply approval workflows to items.

The users of the apps take a look at the protoypes and start to provide feedback. Requests include things like:

  • Can a row be highlighted in red if some field drops below a specific number?
  • Could a link be added to the view item form that takes us straight to a specific view?
  • We don't always really like seeing the Alert Me functionality, can this be hidden for some of the lists but left on for others?

The developers know that technically they can do all of these things and they want to say yes to the business. This is a mistake.

It is a mistake for a couple of reasons. The business has been promised rapid application development by whoever sold them SharePoint. They may even have been told that this assumes you use as much out of the box functionality as possible and avoid code customisation if you can. Understandably, what they don't realise is that the things they are asking for are customisations that will require code to be written, tested, deployed and maintained.

It is up to the developers or IT managers to explain this to the business users and make it very clear whether what is being asked for is out of the box or whether it is a code based customisation.

Another reason it is a mistake is that the requests to turn off alerts or add links in unusual places are significant changes to the standard interface. One of the benefits of using SharePoint is that it provides a consistent platform and each change to that platform chips away at this consistency. The benefit of a consistent interface is that once a user has mastered one application or area of SharePoint they should be able to open any other SharePoint site and feel immediately at home. The changes mentioned may sound small but over time can build up to mean that some areas of SharePoint become almost unrecognisable. This will lead to an increase in support calls and training costs as users will be confused by these inconsistencies and ultimately this can hurt user adoption of the platform as a whole.

I'm not saying that you shouldn't use code based customisations or alter the user interface in any way but these customisations do come with an overhead that needs to be understood by the business. The danger is that if this is not clearly explained the original expectations of rapid application development and the benefits of a consistent platform are not met and the business starts to question whether these claims were ever true or even worse, whether any claim made about SharePoint is true!

An informed choice needs to be made by the business on a per application basis as to whether they are prepared to invest the extra time and effort to get an application that meets 100% of requirements. Or, decide that it is better to have something delivered far more rapidly that meets ~80% of the requirements and loses some of the nice to have elements. In addition, there also needs to be someone in the business taking an overall view of what customisations are acceptable across the platform to preserve interface consistency for the benefit of all applications.

This is clearly not an all or nothing choice and there is a sliding scale of just how much customisation the business is prepared to take on. Once people come to terms with and fully understand these choices and trade offs they usually feel much happier about SharePoint and the best way to deliver applications for their business. Ultimately SharePoint is about giving the business the tools to do a job in the most effective and efficient way possible and sometimes this means having to say no to some requirements.

What do you think? Is this something you have seen happening at companies you work with? Are there other mistakes that you see happening more frequently?

JQuery Library for SharePoint

17 April 2010

Up until now I have tended to agree with people like Jeremy Thake who warn against the use of jQuery in your SharePoint deployment. **UPDATE** - see comments from Jeremy below clarifying his position on who should be using jQuery.

However, a common requirement from users is to provide cascading drop down boxes in the new and edit item forms which SharePoint just doesn't provide out of the box.

I then came across Marc Anderson's excellent jQuery library for SharePoint which provides a solution for creating cascading drop downs as well as several other very useful functions.

Although this does not address all the issues of using jQuery I think that it helps to overcome some of them.

  1. The cascade function has already been tested for SharePoint 2010 so I know it won't break when we upgrade.
  2. It is a library which can be reused across SharePoint with minimal additional script needing to be added to individual pages so it can be maintained and updated centrally.
  3. It is a Codeplex project that is relatively popular so I can have some confidence that it will continue to be updated and even if it isn't I have a copy of the library that I can update myself if anything ever became broken in future versions of SharePoint.


For more information on the library and the SPCascadeDropdowns functionality take a look here.

SharePoint Custom Workflow Visual Studio Solution

16 January 2010

There are loads of articles and blog posts about creating SharePoint 2007 custom workflows using Visual Studio but most of them only tell part of the story or have certain steps missing. Nick Swan has probably come closest with his post for Visual Studio 2005 but even with a post as comprehensive as this it is clear from the comments that it is something people still struggle with. Rather than rehash all of those posts I thought it would be more useful to provide an example Visual Studio 2008 solution that is already set up and ready to go.

This article does not aim to be a comprehensive guide to setting up a custom workflow. It is aimed at a .net developer audience who are already familiar with SharePoint and InfoPath development but who just need a bit of help bring all the bits of SharePoint custom workflow development together into a working solution.

This solution was created using STSDev v1.4 which gives a good starting point for a sequential workflow solution and automatically creates a .wsp file whenever the project is built. If you are not familiar with STSDev projects the .wsp can be found in the Deployment folder of the project.

In the project I have included the more common generic elements for a custom SharePoint workflow:

  • An InfoPath initiation form that allows the user to provide information to the workflow task. In this case the workflow task title is set and a property is stored to be displayed later on the task form.
  • An InfoPath task form that displays information from the initiation form and allows the user to approve or reject the the item.
  • The sequential workflow itself - wiring this up is often a place where people miss something or make mistakes.
  • A WorkflowTestInitForm.cs file that is used to make the information typed into the initialisaton form available in code. See comments in this file to generate your own.
  • An ItemMetaData.xml file that is used by the InfoPath task form as a secondary data source so that the information supplied by the initiation form can be displayed.

The code has been commented to provide additional information and guidance on how to set up your own workflows. For the solution to work the only thing you have to change before building and deploying the .wsp is line 62 in SequentialWorkflow01.cs - the task assigned to property must be set to a user that is valid for your environment.

To open the solution just save this zip and extract in your development environment - AidanWorkflowTest.zip (91.97 kb)

SharePoint Customisation - OOTB vs SPD vs Custom Code

18 November 2009

@joyknows has posed an interesting SharePoint question via Twitter -

What would you say are the primary strengths and weaknesses of OOTB customisation vs. SPD vs custom code?

This one is definitely going to take more than 140 characters so here goes...

Out of the box (OOTB) customisation allows any end user familiar with SharePoint to create sites, lists and web parts through the user interface to produce something that meets their specific requirements.

Strengths -

  • Very quick to create customisations
  • Anybody with basic SharePoint knowledge can do it
  • Forces users to create solutions in a "SharePoint way" which encourages consistency

Weaknesses -

  • Doesn't provide much flexibility - compromises have to be made with requirements
  • If you want to repeat the same customisations again then options for recreating the solution are limited - manual repetition of creation steps or templates

SharePoint Designer (SPD) customisation allows power users to get a bit more creative and make use of some of the more advanced options in SharePoint such as custom workflows and connecting to differnt data sources.

Strengths -

  • More options for customisation - will fulfill more of the original requirements
  • Make changes to master pages and page layouts - create a completely new look and feel

Weaknesses -

  • Difficult to deploy customisations made using SPD to other sites - eg. A custom workflow created in SPD is applied to a specific list and cannot be resused on another list. The only option is to manually recreate the workflow again for the next list.
  • It is possible to do a lot of damage very quickly if put into untrained hands
  • Once files are customised by SPD they cannot be changed by custom code

Custom code requires a SharePoint developer to write it but it is the most powerful option that opens up the full SharePoint API, web services and any other code you want to use to customise your solutions.

Strengths -

  • Provides the most options for customisation
  • Customisations can be packaged up as features that are easily deployed and reused in multiple solutions
  • Deployment can be controlled and governed more easily as customisations can only be deployed by people with SharePoint admin permissions

Weaknesses -

  • Requires a SharePoint developer
  • Takes longer to achieve the same results

The above lists are a very brief summary of the pros and cons for each option. In reality it would be possible to have lengthy discussions about each but I think these lists provide a fair summary that should help as a primer for the more important discussion - which option should I choose?

As with most decisions like this the short answer is - it depends. In this case it depends largely on the trade off that you are prepared to make between speed of solution develoment and flexibility/meeting the original requrements exactly.

If you need something fast and are prepared to compromise by not meeting the original requirements 100% perfectly then OOTB is the way to go.

If, on the other hand, you need to have a solution that ticks off every requirement perfectly, that can be easily reproduced across lots of sites and you are prepared to wait a bit longer for delivery then custom code is the answer.

SharePoint Designer is a middle ground that combines the best and worst of all the options. In my opinion it should only be used to quickly prototype something that you later turn into a well packaged custom code solution or where you have to customise to meet a requirement but do not have SharePoint development resources available.

In the interests of full disclosure I am from a SharePoint development background and have also spent a significant amount of time working with SharePoint whilst being constrained to only using OOTB customisations. As a result I am not what I would describe as a typical SharePoint dev - ie. Reach for Visual Studio first and ask questions later!

This may sound like a betrayal of my SharePoint developer brothers and sisters but I would argue that custom code should only be used once you are sure that what is being asked for cannot be achieved using OOTB customisation. That may sound obvious but it is easy to take requirements on face value and assume that what the end user is asking for cannot be compromised on which makes it look as though custom code is the only option. In reality if the end user understands that they can have a solution that meets 80% of the requirements delivered in 2 days using OOTB or a solution that meets 100% of the the requirements in 10 days using custom code those requirements that were previously set in stone suddenly become a bit more flexible.

So in summary, and just to be clear so I don't get flamed by all the SharePoint devs, custom code is great. It provides the most number of customisation options that can be deployed to your SharePoint farm in a repeatable and controlled way. However, I would choose OOTB wherever possible in the interests of speed of delivery and productivity even if that means using your powers of persuasion to talk the end user into settling for a solution that doesn't tick off 100% of the original requirements but does meet the core ones, they will thank you in the end!

SharePoint support turns from a trickle to a flood

01 November 2009

When Microsoft Office SharePoint Server 2007 was in beta, and for some time after it was given a full release, the level of support and documentation available was, at best, pretty sketchy. Over time Microsoft have improved what is available on MSDN and Technet as well as publishing best practices but what really saved MOSS 2007 and the people who work with it was the SharePoint community who have done a great job in supporting each other with blog posts, forums, wikis, white papers and the like.

Given that history, it is fantastic to see the amount of information being made available before the public beta of SharePoint 2010 is even released. As the NDA on SharePoint 2010 was lifted at the SharePoint conference in Las Vegas there was a veritable blizzard of blog posts from various SharePoint insiders.

Other than watching the SharePoint conference key note one of the best summaries of top new features came from Joel Oleson and also includes further links to the MSDN and Technet documentation for SharePoint 2010 as well as what looks like quite a promising Developer Centre being created by Microsoft that is currently tagged as in beta. Joel has also started doing some presentations on the new admin features of SharePoint 2010 with further information on his blog.

Andrew Connell was quick off the mark with 3 blog posts on improvements to the Web Content Management aspects of SharePoint 2010 and a further post on the new service application architecture.

Bil Simser filled in some of the details around improvements to look up columns and the addition of ratings functionality.

Spencer Harbar has produced a great post on the improvements to the development tools available for SharePoint 2010 which will all be very welcome given the amount of criticism Microsoft got from the development community for not doing more in this area for the previous version.

Another brilliant developer post on the factors that could persuade asp.net developers to start using SharePoint comes from Jeremy Thake the man behind SharePoint Dev Wiki. This is a wiki that was started as a reaction to the lack of a definitive resource for SharePoint developers and has become the place to go for reference material and guidance on SharePoint development. The site has now been extended to include a SharePoint 2007 Administration wiki and a shiny new SharePoint 2010 Development wiki which is already starting to be filled with content.

A communication method that wasn't available when the 2007 version was released was Twitter. Not being able to go to the SharePoint conference was frustrating but Twitter came to the rescue and at times it was almost like being there. Well, ok, maybe not but it did provide a rich stream of information about new features directly from the people who were lucky enough to be there. This allowed the people who couldn't be there in person to get a glimpse of some of the detail being revealed during the sessions and to see beyond the headlines of the keynote.

Back in the beta days of SharePoint 2007 it was often a case of feeling your way and piecing together bits of information from lots of different sources to achieve the end result you were looking for. I think I can say with some confidence that those bad old days are in the past for SharePoint. It is now a huge success story for Microsoft and they are supporting it better than ever with documentation and tools. In addition the community of people working with and supporting SharePoint has grown massively over the last few years and this is where a lot of the best content is going to come from. This time round the problem won't be the lack of information the issue will be that now the trickle has turned to a flood can we keep up with all the content being produced? This is where inititiatives like Dev Wiki can really help to put some structure to that content and also allows us to give authority to the best bits.

Have you come across any other great SharePoint 2010 posts that are worth sharing? If so please add them in the comments.

Easily import data from CSV and SQL to a SharePoint list

09 October 2009

CSV and SQL importer wsp file

This SharePoint feature allows you to quickly import data from a CSV file or a SQL stored procedure to any custom SharePoint list.

Once you have added the solution to your farm and activated it on your site collection an additional menu option will be available on the Action menu of each custom list that will take you to the import CSV or SQL page.

Simply select which option you want - either import from a CSV file or import from a SQL stored procedure. Next, browse to the CSV file or enter the SQL connection and name of the stored procedure and hit the Import button.

There is a check box option to delete all items from the list before doing the import which is not selected by default.

IMPORTANT - the first line of the CSV file must contain the names of the SharePoint list columns you want to import the data to. Eg. If you want to import data into a list that has two columns called Title and Description then the first row of the CSV file will be Title, Description.

If you are using SQL then the stored procedure for the example above would need to be something like: SELECT Title, Description from [TableName]

**UPDATE 16/12/2012 - I have now updated the CSV Upload portion of this feature to work as a SharePoint 2013 Hosted Solution.

SharePoint User Group UK meeting - 27th August

05 August 2009

Dux Raymond is visiting the UK in August and will deliver sessions on the following at Microsoft's London Victoria office on 27th August:

7 Ways to Leverage SharePoint for Project Management Success


Best Practices in Gathering Requirements for SharePoint Projects

Register here - http://suguk.org/forums/1/20147/ShowThread.aspx


Trouble shooting SPWeb object closed or disposed

22 May 2009

I recently came across an issue on a WCM site where the following error was being shown whenever a dropdown selection was changed on a custom web part:
SPException: Trying to use an SPWeb object that has been closed or disposed and is no longer valid 

This looked like the SPWeb object was being incorrectly disposed of but careful inspection of the web part showed that best practices for disposal of SPObjects had been followed .
To try and track down the cause of the error and to really satisfy myself that it wasn't the web part causing the issue I removed all references to SPWeb from the custom web part. The error was still appearing so this ruled out bad coding practice in this control.
The next step was to take a look at the other controls on the page. As this was a WCM site there were a number of custom controls being used for navigation and other functionality.
It didn't take too long to track down the culprit in a control being used to set the site title in the browser title bar. This contained the following:
using(SPWeb web = SPContext.Current.Web)
   //some code
When the dropdown selection was changed a postback was fired and this piece of code brought the site crashing down.
This was because both the using statement and the use of SPContext handle garbage collection so the SPWeb object was being disposed of twice and as it didn't exist on the second dispose the error above was thrown.
Once corrected the code looked like this:
SPWeb web = SPContext.Current.Web;
//some code 

Most of the links about this error on the web will point you towards the issue being incorrect disposal of objects but what is learnt here is that it might not be a coding issue in the control that seems to be causing the problem. In this case it was the postback being fired by the control rather than the control itself that was triggering the error. The root cause was actually a completely different web part on the page.

SharePoint projects are like vegetables

01 May 2009

SharePoint is often marketed as a way for businesses to deliver results quickly. The breadth of capabilities in SharePoint is impressive straight out of the box – collaboration, search, business intelligence, web content management and the rest. Because you get all of this without any custom development it is possible to deliver SharePoint solutions to the business very quickly without having to write a line of code.

At this point the title of my post may seem a little misleading. SharePoint and vegetable growing are definitely not similar in terms of speed of delivery or quick wins but bear with me.

I recently planted some vegetable seeds and I can now tell you from my limited gardening experience that it takes a while for lettuce, potatoes, chillies and tomatoes to make progress from being tiny seeds to being little shoots. Delivering results in the form of tasty things I can eat still seems a very long way off.

In a world where we are seemingly obsessed with instant gratification growing your own vegetables forces you to slow down and accept that whilst there are things you can do to encourage growth there is also a natural cycle that cannot be rushed.

Whilst sitting in the garden wondering how long it was going to take before I could make a meal from the things I was growing I started thinking about how different this was to how I spend my rather more fast paced working life delivering SharePoint solutions. However, the more I thought about it the more similarities I saw. A truly successful SharePoint implementation isn’t going to survive based on those initial quick wins it is going to be judged on the value that it provides to the business over time as it continues to grow and develop to maturity. I started thinking about the SharePoint projects I have been involved in and particularly those that involve intranets and lots of business users. Whilst SharePoint does provide a huge amount out of the box that can produce quick wins and deliver fast results there also seems to be a natural cycle to SharePoint success that cannot be rushed, although there are things you can do to speed it up.

Thanks for making it this far, I promise that this is where the similarities between vegetable growing and SharePoint start to become clearer, in my slightly warped mind anyway. In any SharePoint or gardening project there is initially a flurry of activity where the infrastructure or garden is prepared. Any existing content or compost is migrated from the current infrastructure or garden to provide a useful or fertile environment for users or seeds to become a part of.

The users or seeds are then given access to the content or compost and the first shoots of use or growth appear. At this point everything looks good and you could be fooled into thinking that your job as an IT professional/gardener is over, think again. Those users or seeds are going to need supporting or watering and some of them are simply going to lose faith with the project or wither and die unless you provide training or protection from the elements.

Over time the content or garden can become a bit of a mess and data cleansing or weeding is necessary otherwise your users or vegetables will not be able to get to the content or nutrients they need to prosper and meet their full potential. As with all SharePoint project or gardening tasks this is not something you can just do once and tick it off a list. It is a never ending process of supporting or watering, training or protecting, removing clutter or weeding.

Often a SharePoint project is seen like any other IT infrastructure project that has a start and an end date which will produce immediate results as soon as the magical project end date is reached. This is the gardening equivalent of digging over your vegetable patch, adding compost and nutrients to the soil and then going back indoors thinking your job was done. People are then surprised when nothing grows and the vegetable patch is still empty come the summer. When this happens in a SharePoint project it is usually the technology that gets the blame for underperformance rather than a lack of governance or assurance plan.

The concept of SharePoint as an ongoing process rather than a fixed term project is crucial to the success of SharePoint within an organisation. Although there are quick wins to be had when you first implement SharePoint depending on your circumstances the tastiest rewards will only come in time if you carefully tend to your installation and feed your users the right mix of training, knowledge and support.