Relocated VPP folders in EPiServer R2

One of the new features in EPiServer R2 version is the relocation of the system folders. In previous versions they lived alongside the rest of the site files, where you could find them, understand them and occasionally swear at them. With the new Installation Manager, they’ve been moved into Program Files.

I’m struggling to see the benefit. For perfectly sensible security reasons, applications rarely get unrestricted access to places like Program Files. And if the goal is to keep the development environment reasonably close to the deployment environment, generally considered a good idea unless you enjoy debugging mysterious differences at three in the morning, it seems simpler to point the VPP path back to the traditional location with the rest of the project files.

I’ve seen the argument that moving the folders sends a message to third-party vendors to keep their dirty fingers out of EPiServer’s cookie jar. Fair enough. But anyone who is reckless enough to start rummaging around in the EPiServer files under Util probably isn’t going to be stopped by file locations. Move the cookie jar to another cupboard and the same person will eventually find it.

EPiServer Once upon a time in EPiServer land.
Then there’s version control. Files such as web.config can become troublesome when checked into source control because VPP paths are absolute and may differ between developers. Nothing says teamwork quite like a configuration file containing a path that only exists on David’s laptop.

A cleaner solution might be to move the VPP paths out of web.config entirely and put them in a separate configuration file, much like connection strings. Keep the machine-specific plumbing away from the configuration everyone is expected to share.

And as a final little garnish, the actual name of the Program Files directory can vary depending on the language of Windows. Because apparently absolute paths weren’t entertaining enough already.

Maybe I’m missing some grand architectural wisdom here. If so, feel free to illuminate me. Preferably before I move everything back.

Related posts

Posted in category Development.

4 comments

  • avatar
    Fredrik Haglund (INEXOR AB)
    05 Dec, 2008
    Let me start with that I do agree that source code versioning might be an issue. But it is possible to just copy the files from program files into your project as before if you prefer that. There is already other external dependencies that is troublesome to just check in - like the EPiServer Services. EPiServer Community does stuff during installation that register events and also has absolute paths in web.config. ImageVault requires 3 external applications to be installed and licenced to work, etc. But yes, absolute paths in web.config is a pain! I think the main reason that EPiServer’s edit and admin user interface is moved outside the wwwroot is that it is then possible to support both Web Application Project model and the Web Site Project model. The later also enables use of the free Visual Web Developer Express Edition. This makes it possible to target web site developers that are more interface designers with html/css skills. /Fredrik
  • avatar
    Steve Celius
    05 Dec, 2008
    I don't like this either :-) See http://labs.episerver.com/en/Blogs/Steve-Celius/Dates/112266/10/EPiServer-System-Files-Have-Moved/ for my view. /Steve
  • avatar
    Reine
    05 Dec, 2008
    Hi Fredrik and thanks for your input! It seems that Microsoft has realized that the community didn't like the Web Site Project model, so the Web Application Project model from 2003 is back in Visual Studio 2008 (without the need for additional add-ons as were the case with vanilla Visual Studio 2005). The SP1 release of Visual Web Developer Express also adds support for the Web Application Project model, so this should probably not be a show-stopper.
  • avatar
    Reine
    05 Dec, 2008
    Nice post, Steve! Thanks for the note on upgrade issues with Subversion.

Leave a reply