One of the new features in EPiServer R2 version is the relocation of system folders. In previous versions they were stored in the same folder as the other site related files, but now they seem to be installed in Program Files by the new Installation Manager.
I fail to see the benefits of this. For safety and security reasons, software rarely have complete access to areas such as Program Files. To keep the development environment as similar to the deployment one as possible, the best way seems to be to set the VPP path to the classic location with all the other project files.
I read someone saying that this would act as a message to 3rd party vendors to keep their dirty fingers out of the cookie jar, but if someone is careless enough to mess with the EPiServer files in Util they will surely do so regardless of their location.
Once upon a time.
And then there is the issue with version control. Files such as web.config can cause trouble if they are kept under source control, as VPP paths are absolute and can differ from one developer to another. A suggestion here would be to break out the VPP paths from web.config and place them in another config file, just as with the connection strings.
Also, the name of the Program Files folder can change from one system language to another, which can add further to the confusion.
Feel free to illuminate me if you have any ideas on this.
Related posts
4 comments
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
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
Hi Fredrik and thanks for your input!
I see your point but I wonder why EPiServer with their advanced .NET product would target interface designers?
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.
Nice post, Steve! Thanks for the note on upgrade issues with Subversion.
Leave a reply