I have just been tidying up my masterpage library in a WCM sitecollection and came across an issue when trying to delete some master pages.

When trying to delete I got the following error:

I know that this is not the case - no other pages use this master page!

Fortunatley there is a workaround for this. Simply create another folder in the masterpage folder and then drag the master page you want to delete into it. Then delete the folder and your master page is gone.

If you name a site or page with an & and you want to also use the breadcrumb SiteMapPath control then you are going to see some nasty results. This is because the control outputs "&amp;amp;" instead of "&amp;".

To fix this you need to make a change to the sitemappath control. Simply include SiteMapProvider="CurrentNavSiteMapProviderNoEncode" as follows:

So you are trying to use a custom css in your master page but the nice shiny font you are trying to display isn't showing up! The reason for this is that core.css will be called after your custom css file leaving your text displaying as verdana or arial.

The fix for this is to declare your custom css file in the master page settings of your site - (Site Actions/Site Settings/Master Page). The result is that your custom css will be applied after core.css and the font you specified is used.

I recently needed to add a reference to a web part where the dll had not been strongly named. The result of doing this was a build error complaining about the unsigned dll. I did not have access to the source code so couldn't resolve the issue by rebuilding the dll with a strong name. Instead I used the ILMerge tool which can be found here.

Rather than using the tool for it's intended use of to combining a number of dlls into a single dll I used it to sign my single dll using the following command line syntax:

I have recently been working on a web part that accesses a SQL Server that is installed on a different server to the MOSS web front end. This web part worked great running under my own credentials which also had access to the SQL Server....until I tried running the page from a web browser on my own machine. At that point I get a login failed error as my credentials did not get as far as the SQL Server.

This was due to the double hop issue in Windows networks that only allows an application to pass the credentials it is running across one server hop. This meant that whilst running the web part from the MOSS Server I could hop once to the SQL Server and get the data. When running the web part from my PC I hopped once to the MOSS Server and from there was unable to pass my credentials across the next hop to the SQL Server.

After doing some investigation I realised that I could get around this using Kerberos and configuring AD correctly but as I don't have access to AD this is something I wanted to avoid.

Instead I came to the realisation that I didn't really need to pass the logged in user's credentials to the SQL Server as the information being pulled out is available to all users. At first I thought the solution was to use impersonation by adding a service account to the Web.Config of my SharePoint web application which is then used to access SQL.

This user is then given permissions on SQL.......but that didn't solve the problem entirely!

Although my web part could now access SQL the whole of the SharePoint web application was running using the service account. The downside of this is that the user is no longer logged in as themselves so all their security permissions to document libraries, lists etc. are no longer applied.