Mark Everard

Hello, I'm Mark – a PhD physicist turned technologist / architect.

Archive for May, 2010

Default EPiServer Web.Configs for IIS6 and IIS7

without comments

I consider myself lucky to be running a local development environment using Windows 7 which means all of my development sites run off of IIS7 (unless of course, I running them through the built-in Visual Studio web server).

IIS7 is dramatically different to IIS6 and Microsoft went to great pains to provide  backwards compatibility (classic/integrated pipeline). However we’re now stuck in a technical limbo where we often end up running sites across both IIS versions.

Recently I’ve been working on some older EPiServer sites which are hosted on IIS6 boxes in production but I’ve had to develop locally on IIS7. Working across different environments like this is painful.

Whilst there are upgrade scripts and also a useful technical note about the differences between the configuration files on EPiServer World, its still all too easy to get to the stage where you can’t get elements of the site to work as intended and you feel you’ve got no option but to compare configurations files line by line to ‘spot’ any differences. This especially difficult when considering the size of the web.config files in EPiServer and ASP.NET 3.5 in general.

Often I’ve just wanted to start from scratch with a default EPiServer web.config file targeted at either IIS6 or IIS7. If you ever find yourself in this  same configuration management hell then this little tidbit may come in handy.

Default  EPiServer web.config files for both IIS6 and IIS7 can be found in your %PROGRAMFILES%EPiServerCMS<version-number>Application directory. These are called Web.Config.6 and Web.Config.7 respectively.

Obviously don’t edit these files, as they are no doubt used by the EPiServer Deployment Center when creating new local sites, but as a fallback to a configuration file that works – then go for it.

MultiplexingMembershipProvider

Written by mark

May 21st, 2010 at 2:53 am

Posted in ASP.NET,EPiServer

Maintaining a successful software platform

without comments

There have been a few scenarios played out recently that have got me thinking about ‘the effort required to maintain and drive a successful software platform’. Its clearly a difficult balancing act as not only do you have to develop a product with the functionality that end users desire, you also have to create a ecosystem of developers who are able to leverage your platform to create cool products!

Apple’s very public spat with Adobe over Flash support clearly demonstrates the difficulties with maintaining the right balance between the end-user and developer. Apple’s heavy handed approach to setting their strategic technological vision for the ‘good’ of iPhone / iPad user experience has ostracised a large section of experienced rich-interface developers, who were excited at the steps that Adobe had taken to enable their ideas on the Apple platform. Whether or not this was the correct call from Apple will only be borne out in time. If I were Adobe, I’d be throwing my weight behind Android and creating some great Flash development tools in the hope that Flash developers produce the killer apps to show that Flash on a mobile is a ‘workable’ technology.

Microsoft have been taking a different approach in recent years. Its latest successes (I’m not including Windows 7 in this – in fact, is that even considered a success?) are built on the foundations of the .NET platform, and have been driven entirely by a open, honest focus on developers and empowering them by giving them access to the best development tools (seriously Visual Studio is an amazing bit of kit). Their approach to Windows Mobile confirms their belief in this methodology. Stuck with a mobile offering that paled in comparison to competitors, they went away for a while, re-thought their whole approach (undoubtedly influenced by Apple’s App store success) and created Windows Mobile 7. In one swift announcement they turned me (and any other .NET developer) into a mobile developer. It will be interesting to see whether they can deliver an end-product that stands up too.

Being able to throw away a partially-successful platform and start again is a luxury that only the major players like Microsoft, Google, Apple can afford to do. Most smaller platform vendors can’t justify starting over from scratch. In fact, doing so could be the the single worst strategic decision they could make.

Instead the only choice left is to evolve and work extra-hard to improve the areas that need the most attention. The first step towards any solution is always admitting the problem.

An error doesn’t become a mistake until you refuse to correct it.

Orlando A. Battista

This then brings us back to the original conundrum. Where do you focus your development efforts? Who really is the most important user of your platform? Developer or end-user?

Renowned CMS anti-hero @McBoof approached these issues with his challenge to CMS vendors to rate the following CMS ‘features’ in order of priority:

  • Editors – A user interface that is a editor or publisher’s wet dream
  • Performance – The fastest, most stable and scalable CMS in the world
  • Features – The richest set of features any CMS could dream of offering
  • Developers – An open, standard, extensible product that makes developers salivate
  • Website – A product that can give you a kick-ass website, really really quickly

What the results of this semi-serious survey actually tell you is open to debate….. but what is clear is that none of the CMS platforms mentioned excel across all areas. Simple rule of life: You can’t please all of the people all of the time!

Speaking as a developer, I obviously want to use tools and APIs that help me create solid, maintainable code and that generally means using the newest technology (ORM’s, Dependency injection, etc etc).

However I’m also aware that adding new features/APIs to existing platforms takes time and some features may rightly or wrongly not be considered a priority. For example, how long has it taken Microsoft to allow developers full control over rendered client Ids in WebForms? A well-known ASP.NET limitation which has been the bane of every front-end developer since the dawn of time (aka VBScript). Taken in isolation this didn’t make .NET a bad platform, just a slightly less perfect one.

This is where (as @joelabrahamsson pointed out on my last post) the development community should take the lead and not only point out any issues to the platform providers but also attempt to show the way and to provide sensible solutions/fixes to any issues that may be causing development woe.

This shouldn’t be a one way relationship. In return, a developer should expect open discourse and two way communication with the platform providers. Sharing things such as a development roadmap allows developers to make up their own mind about the platform’s direction and to have input on the proposed pathway. Any contentious proposals will soon be flagged up by the eager community, giving a chance to either re-think or to justify the initial line of thinking, as Apple’s Steve Jobs attempted with his ‘Thoughts on Flash’ open letter.

To me – that openness is the key to a successful platform. It gives great buy-in to the potential developer knowing that they can shape not only their end product but also help to shape the future of the entire platform.

Written by mark

May 6th, 2010 at 9:12 pm

Posted in Opinion