Day 32 of one-blog-per-day-until-Christmas, and though this is just another vNext posting, I'm pretty passionate about this one.
The Problem
Thesedays. It's all about the cloud and hosted services, baby. Not that hosted services haven't been around for a while, but anyways the point is that the number of shared hosting environments are probably increasing exponentially as we speak, as are the number of uses of the buzz-word "cloud". But I digress.
So... we have established (thoroughly) that more people are using SharePoint in a hosted environment. Great! But, here's the rub. SharePoint with its development platform hat on becomes very limited in hosted scenarios. Most service providers, like the one that is hosting this simple WSS site, don't want you meddling with the GAC, or indeed the 12 Hive – you typically only have access to browser or SharePoint Designer-based customisations. This greatly limits your potential uses and expansions of SharePoint, particularly if you're a developer with a desire to do some serious customisations.
Now, half the issue is that SharePoint hosters typically don't provide access to the inetpub area corresponding to your site (web application), so even if you wanted to you can't upload things like bin-folder deployed web parts. SharePoint hosting usually ain't as flexible as traditional ASP.NET web hosting where you get at least FTP access to do what you want within your inetpub world.
But, even if you could get access, there are three main limiting factors I see that stop this being useful:
- Custom pages that you place in that area wouldn't be loadable – SharePoint's custom handler simply ignores them unless they're application pages contained in /_layouts, or actually registered as site pages in the content database. So http://mypage/foo.aspx may well map to inetpub\wss\virtualdirectories\mypage\foo.aspx, but stiff shrewsberries.
- Even if they weren't ignored and you could map e.g. http://mypage/foo.aspx to inetpub\wss\virtualdirectories\mypage\foo.aspx, those pages wouldn't be contextual based on the site they were in, e.g. http://mypage/foo.aspx vs http://mypage/subsite/foo.aspx. You'd just have one for the entire application.
Aahh – so just create a site page and store it in a document library or directly in the virtual file system via SP Designer I hear you say – but due to the safe mode parser site pages not ghosted off the file system are fundamentally limited in what you can do with them.
- A large number of code artefacts only work with GAC deployment, such as event receivers. This means that even if you did have access to the BIN folder it would be limited in its usefulness.
All of this adds up to poor code-level extensibility of SharePoint in hosted environments... I'm ignoring other extensibility here including tricks like using JQuery inside content pages... I'm talking pure, hard-core code.
Possible Solution
Introducing... the Web Application Hive!
Here's what I propose:
-
Each Web Application gets a folder named /Hive (or something more official and less controversial) in the file system under the relevant directory in inetpub/wss/virtualdirectories.
-
An additional /_hive/ virtual directory is provisioned for each site that points to /Hive for that web application e.g. http://myapp/site1/_hive/foo.aspx and http://myapp/site2/_hive/foo.aspx both point at "foo.aspx" in the root of the hive – but foo.aspx could access e.g. SPContext.Current.Web as per normal _layouts files and spin some magic.
-
More SharePoint artefacts are allowed to work with BIN folder deployment so that the /_hive area would be useful.
- SharePoint hosters let people in to their relevant inetpub area as if it was just a standard, fully extensible .NET site.
At the end of the day, what all this would give is something akin to application (_layouts) pages but on an app-by-app basis. So you get all the benefits of _layouts pages – not customisable, not limited by the safe mode parser security rules, etc, but in a way that can be self-contained to a web application and therefore useful in hosted scenarios. This would also have the nice side-effect in non-hosted scenarios of giving you a place to contain customisations on an app-by-app basis instead of messing up the 12 hive... renamed the global hive now for my purposes.
Workarounds (For Now)
I guess you could actually set up a structure like this right now – but this wouldn't grab for any new sites (you'd have to go back in and recreate the _hive virtual directory each time), Also, this assumes you have access to add virtual directories, which you usually don't with SharePoint hosts... the whole issue in the first place!
Question: would the Web Application Hive (WAH) be as useful to you as it would to me? First person to comment wins a mystery prize.
:) Matt