If you’ve read Fredrik's recent blog postings, or checked the folder of a newly installed R2 site, you might have noticed that the list of folders has shrunk.

“Private” files, or system files, belonging to EPiServer has been moved out of the web site folder and into the Program Files folder. These are files that you should not touch anyway as they are system files and important for EPiServer and especially for Edit and Admin mode to work.

I do not know the reasoning behind doing this, but some people believe that the idea is to store these application files where application files are supposed to live. The Program Files directory. I understand the sentiment, but I respectfully have to disagree.

Minimizing Dependencies

For a long time, I have been an eager advocate of committing as much as possible of your site into source control. The point being that it should be as easy as possible to get an old site up and running, or for someone else to join a project. Bring down the source code, create a site in IIS, compile and run. If this is an older project, you need to get a backup of the production database, if it is an ongoing project, you should already have one available.

I know that the world is not as black and white as I’d like to pretend in this case. You might have other dependencies in your project that you need to download, but I like to submit these too under source control. You should always be able to open a project later on with the requirement it had when it was stopped.

In one year, the current version of EPiServer is not the same as you used when you started developing your site, and with this new feature, you will have to get a copy of the system files for edit and admin to work.

Upgrading Breaks if You’re Using Subversion

Worse, if you’re using Subversion as your source control system, and want to upgrade from pre R2 to R2, the installer crashes. You need to export the site out of source control, upgrade and and re-submit.

Bummer!

If you’re using Visual Source Safe, and check in the UI folders, in pre R2, upgrading will also fail as the files will be read only (unless you check out first.) This makes sense, and is how Visual Source Safe works out of the box.

So - if you’re using Subversion (and you should!) you need to take extra care when upgrading to R2.

Going back

I don’t like this way of doing things, not at all, and I want my old way of working back. Why break something that works perfectly well in the first place? Luckily, we can revert to the pre-R2 way of working.

If you open web.config, locate the virtualPath providers and you’ll see these:

<add name="App_Themes_Default"
     virtualPath="~/App_Themes/Default/"
     physicalPath="C:\Program Files\EPiServer\CMS\5.2.375.7\application\App_Themes\Default"
     type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider,EPiServer" />
<add name="UI"
     virtualPath="~/GUI/"
     physicalPath="C:\Program Files\EPiServer\CMS\5.2.375.7\application\UI"
     type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider,EPiServer" />
<add name="UtilFiles"
     virtualPath="~/Util/"
     physicalPath="C:\Program Files\EPiServer\CMS\5.2.375.7\application\util"
     type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider,EPiServer" />
<add name="WebServiceFiles"
     virtualPath="~/WebServices/"
     physicalPath="C:\Program Files\EPiServer\CMS\5.2.375.7\application\webservices"
     type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider,EPiServer" />

Copy these directories from the program files directory into your site directory, and remove the lines above. The site should now work as before. It won’t solve the Subversion problem when you upgrade to R2, but it will allow you to check in all the stuff you need for the site to work.

I doubt you’ll be able to update the site using the new installer though, unless someone agree that this whole way of doing things is not the solution to all problems (I can’t see that it solves anything really). I’m hoping for a way to tell the installer to make things work the “old way” and that it will actually check if the site has these virtual path providers configured before an upgrade is done. Perhaps before R2 SP1?

I guess that Xcopy deployment stopped working quite some time ago, and this adds another nail to the coffin.