The next release of EPiServer called R2 is not far away. Roger Wirz have written more about the major features in the R2 release at EPiServer World.
I would like to share some of the smaller improvements I have found during my work with the upcoming release. Everything looks very promising!
EPiServer GUI deleted
In previous release EPiServer filled the web folder with files needed for EPiServer’s own user interface. We had hundreds of files in UI, Util, App_Themes/Default and WebServices that we needed to take care.
EPiServer CMS R2 uses the Virtual Path Provider to mount a a virtual file system for these folders instead. This simplifies version control and deployment!
<virtualPath>
<providers>
<add name="Util"
virtualPath="~/Util"
physicalPath="C:\Program\EPiCMS\5.2.80...\Util"
type="...VirtualPathNonUnifiedProvider..." />
This new way to map a folder into your web application is provided by the new class VirtualPathNonUnifiedProvider.
-
HI Fredrik,
I followed the instructions from Fredrik Tjärnberg blogg in episerver about doing this and have not been able to succed yet. I have done exactly everything that was said in the blog + adding the extra parameters on web.config for the location tags under and I still cant get to the UI in /ui/edit
Here I send you a link to Fredriks blogg and maybee you can help me a little
Thanks in advanced
Diego Delfino -
Hi Diego,
the post above is about the R2 release of EPiServer and if you just set up a new site with EPiServer CMS R2 it should work fine. I cant tell why it is not working for you without any more clues to go on…
The blog article you refer to is more experimental and I would not recommend that for a real project on a older EPiServer release.
/Fredrik
-
Totally uncool.
Just like VPP these paths must be absolute which makes it impossible to put the EPiServer configuration in version control, since all developers have their own installation paths on their machine.
The VPP configuration path problem we solved by putting it on an UNC share that all developers have access to. But what about this?
Now we have to maintain the EPiServer configuration outside source control. That sucks.
-
Mikael,
You can still put EPiServers editor files under version control like earlier if you prefer that.
I think it is good that the default installation is like this because it sends a clear message to all 3rd party vendors (and developers) that you should not modify the content inside these folders because they are managed by EPiServer. I think it will be good for maintainablity in the long run.
You should consider enforcing a company standard on where project are checked out. At Inexor all developers have agreed to place all our files in the same directory and that really makes configuration management much easier.
/Fredrik
-
At the consultant firm where I work we have a lot of customers and different developers. It happens regularly that you have to fix a bug or write a feature on a project you never heard of before. (common problem)
This is why it is important that every project always will
1) Build on clean check out
2) Pass unit tests on clean check out
3) Execute (and work as expected) on clean check outWhen I check out code from the version control repository I want a complete setup. (we even commit the EPiServer binaries to the repository and reference them as “copy local” so that you don’t need to have the correct version assemblies in your GAC)
The need for configuration after each clean check out, because there are absolute paths in EPiServer config, will cost hours in the end because the new developer must find out why his clean build won’t run and eventually call one of the original developers.
Sure you could enforce a project directory standard on the company (and that is a good suggestion), but it won’t really solve the problem. I make copies of the source directory to test things out. I make branches and must have them in different folders because at the same time I need to fix incoming bugs on the trunk.
Solving the “EPiServer absolute path problem” with enforcing project directory standard is in my world just an illusion. I still need to manage configuration files outside the version controlled environment and the moment a junior developer commits his specialized ProjectZ_temp4 configuration file, the problem reaches the surface.
I would like to version control the VPP if I want to. I would like to version control the UI/Util even if I don’t intend to make changes in them. There is no support for this in the current EPiServer configuration schema and that makes this totally uncool.
-
Mikael,
I totally with you here!!!
EPiServer should stop put machine specific settings in web.config. First it was IIS Web Site ID which was removed for good in RC1. Now is this absolute paths and also the references to EPiServer assemblies in GAC thus making xcopy deployment impossible.
What we need is just to get latest version from source control and just run the site. Additional configuration, matching environmental paths and keeping web.config out of SC is just not an option for team development. -
I fail to see the benefits of this. For safety and security reasons, deployers seldom 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.
The only benefit you mention is the message to 3rd party vendors, but if someone is careless enough to mess with the EPiServer files in Util they will surely do so regardless of their location.
Also, the name of Program Files folder can change from one system language to another, which can add further to the confusion. And then there is the issue with version control, as a previous commenter mentioned.
-
Let me start with writing that I do agree with most comments above related to how the source code should be managed and that you should be able to build and run tests by just doing a check-out first.
As a comment to Reine; 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
-
And… 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!
9 comments
Comments feed for this article
Trackback link: http://blog.fredrikhaglund.se/blog/2008/09/25/1-hidden-gems-of-episerver-cms-r2/trackback/