Tag Archives: deployment

Analysis of the Oracle Hyperion Web Part

Leave a reply

This is a post I originally wrote in July 2009 and never got around to properly completing. Because of its age I considered binning it altogether however a quick web search seems to turn up that nothing has changed for this humble web part. This is more of a rant about vendors that can’t be bothered to integrate their products with SharePoint using best practices. The person that ends up suffering is “the SharePoint guy/gal” who is lumped with deploying this rubbish. Hopefully it helps someone else out there that’s stuck in the same boat I once was.

Rewind to July 2009

I was recently given the task of deploying the Oracle Hyperion web part for testing in one of our SharePoint sites. There was no formal requirement for this, it was simply requested because there appears to be no documentation or information available on what functionality this mysterious web part can provide. What better way to find out than to deploy it for testing, right? There are even quite detailed instructions available!

Well stop right there, folks. In fact before you read any further, my recommendation is to run far, far away from this unusual piece of technology. Why? Well let’s start with the high-level changes you’ll need to make to your SharePoint environment:

  • Add the web part itself
  • Configure single sign-on (SSO) – makes sense as Oracle is an external product
  • Create a ‘proxy page’ – a virtual IIS application inside your SharePoint application
  • Install a custom HTTP handler
  • Create a custom database

Hmmm… seems rather unusual so far (particularly that custom database – don’t we already have data stores in both SharePoint and Oracle?). But then read the fine print as it describes three best practice no-nos all on one page (that’s page 71 if you’re following along readers) without even so much as to explain what effect the changes will have.

  1. Set the trust level to Full.
    Say goodbye to security in your SharePoint farm right here. With trust level set to Full, custom code can run without restriction and do whatever it likes. Really Bad Idea. Oracle, please look into Code Access Security.
  2. Replace the default SQL Server session state provider for SharePoint.
    I’ll be honest. I have no idea what they are doing here or why. All I know is that the chances of support from Microsoft on such a fundamental change to how session state works in SharePoint has to be zero.
  3. Comment out the PublishingHttpModule.
    Say goodbye to one of the best features in SharePoint – publishing pages. For yet another strange and unexplained reason, this has to go. Not sure if they put it back somewhere with their custom code, this isn’t mentioned.

Now follow through almost twenty pages, some with screenshots, to configure this nightmare, and that doesn’t included setting up SSO. I like to think I’m pretty good at puzzling out this sort of thing, but this baby has got me beat.

Things I found that might help others… Add the server hosting SharePoint to the Local Intranet zone in Internet Explorer security settings. Otherwise, you might encounter an “Invalid index” message while browsing the repository in Internet Explorer. Also, uninstall the Enhanced Security Configuration from Windows Server to prevent logon issues.

I wonder if anyone, anywhere has been able to successfully deploy this thing? More to the point, why did Oracle bother to even develop it?

Administrators! Stop before deploying that custom code!

Leave a reply

Even with no development knowledge, there’s a simple and quick tool that SharePoint administrators can run before deploying a solution package or web part to get some idea on whether it could cause instability your farm! It’s SPDisposeCheck and is particularly useful to keep an eye on the work done by a third party or even internally, with no developer knowledge whatsoever.

The tool was released by Microsoft in early 2009 to help developers check for memory leaks in their code. However there’s no reason why an administrator can’t do the same. Memory leaks can cause performance problems and general instability in your SharePoint farm. This tool tells you of any potential problems, and here’s how to use it:

  1. Download SPDisposeCheck and install. By default this will copy SPDisposeCheck.exe to C:\Program Files\Microsoft\SharePoint Dispose Check.
  2. Examine the deployment file you have been given. If this is a WSP file, rename its extension to CAB and extract all DLL files. SPDisposeCheck also works on EXE files if you’ve been asked to run a console application.
  3. For each DLL or EXE, run SPDisposeCheck using the filename as a parameter. To be assured of no SharePoint memory leaks, check that the “Total Found” line is 0.

Here’s an example that shows a potential leak:

SPDisposeCheckOutput

If the tool finds some issues then you should query this with the developers. However as the tool itself states, this doesn’t necessarily mean there is a leak! Unfortunately it can report false positives depending on how the code has been written. Regardless, make sure you have an assurance that the tool is run as part of their release process and any flagged issues have been checked. The tool will never miss a problem with a false negative.

It’s as simple as that. Be sure to add SPDisposeCheck to your admin toolkit and don’t let those developers get away with dodgy code!

Debugging file locking in the GAC

6 Replies

Do you ever find that your solution files have been “successfully deployed” according to SharePoint, yet the updated code isn’t taking effect? Perhaps you are trying to debug but breakpoints aren’t being hit when normally there’s no problem. Yet for some reason rebooting the server fixes the problem…

If that’s the case, the reason is probably file locking, most likely to occur if you have assemblies that need to be deployed to the Global Assembly Cache (GAC). If you ever find yourself in this situation, download a copy of the excellent Process Explorer tool, and follow these steps to verify:

  1. Start Process Explorer on the server affected.
  2. Press Ctrl+F, or in the menu click Find, Find Handle or DLL…, or just click the binoculars icon on the toolbar:Process Explorer toolbar
  3. Type the name of the assembly DLL and click Search.
  4. Under the Handle or DLL column, look for any assemblies located in the path C:\WINDOWS\assembly\temp. These lines tell you what process is locking the assembly.
OWSTIMER.EXE is the culprit

OWSTIMER.EXE is the culprit!

The C:\WINDOWS\assembly\temp folder is Windows’ equivalent of “assembly purgatory” where the assembly will sit until Windows can deploy it. If the currently deployed assembly cannot be overwritten as it is already locked by a process then the DLL will stay there until the process releases the lock or ends, or until Windows is restarted (also ending the process).

One example where this problem can occur is when a WSP solution containing custom e-mail event receivers is upgraded. The timer service, OWSTIMER.EXE, executes event receivers via the Windows SharePoint Services Incoming E-Mail job. As the OWSTIMER.EXE process isn’t restarted when a solution is deployed, it will always hold onto the lock for the DLL containing the event receivers. The solution is to restart the Windows SharePoint Services Timer service on each web front end server. If you’re finding this problem in development, WSPBuilder v1.06 adds a “Recycle the Windows SharePoint Services Timer” option.

This problem can also occur when using Visual Studio if certain combinations of add-ins are installed. You can again check this by using Process Explorer and verify if DEVENV.EXE is the locking process. If so, take a good look at the add-ins you actually need. Regularly restarting Visual Studio is very frustrating and will severely cut your productivity!