Integrating EPiServer 7 With MVC - Next Steps

My previous blog post, Integrating EPiServer 7 with an existing MVC site, outlined the initial steps to get EPiServer 7 running. However there are a number of additional steps you may need to take before your site is fully integrated.

Convert any Controllers not in Areas

If your site only contains controllers within Areas then you should not need to make any changes. However controllers in the root of the site will not work by default (at least for me). I found it was best to deal with these controllers on a case per case basis as the best course of action depended on the function of the controller. I implemented one of the following changes for each:

  • Move the controller into an area. This option makes sense if the views for the controller do not have any CMS editable content
  • Convert the controller to be CMS managed. Makes sense if the views need to be CMS editable (inherit from PageController<T> where T is a BasePage)
  • Convert the controller to an HttpHandler. In one case the controller did not have any views or models, it was really just a different entrypoint to the site which ran a bit of logic and redirected. In this case there was no point in retaining the controller as an HttpHanlder could do the same job more efficiently

Disable strict language routing

I encountered a further issue after patching my EPiServer.Core and EPiServer.Framework nuget packages to the latest versions. None of the controller actions in the home controller worked any more except for the Index. This was fairly easy to remedy by disabling the strict language routing, via the episerver/sites/site/strictLanguageRouting config setting.

Deployment Issues

While its all well and good having the site running on your machine, eventually it will need to be deployed somewhere. We handle configuration changes with file transforms and I was pleased to note that the config changes required for episerver deployments are now minimised. Here is a summary list of all the settings we changed per environment:

  • connectionStrings
  • episerver/sites/site/siteSettings/siteUrl
  • episerver.framework/siteHostMapping/siteHosts
  • episerver.framework/appData/basePath
  • episerver.framework/licensing/licenseFilePath
  • episerver.search/namedIndexingServices/services/baseUri

Note, you may need to transform further settings for a load balanced site.

EPiServer UI not deployed

Previously with EPiServer v6 all that was needed to run the CMS interface itself was to install the application on the web server. However the EPiServer 7 UI architecture also has a number of dependencies in the {VPP}\modules folder. So ensure that these files are also present in your deployed environment, otherwise you will probably encounter the following error:

DirectoryNotFoundException: Could not find a part of the path '{Your site path} \Website\ClientResources\ClientResources\packages.config'
Search service configuration

We have the search service configured on a local host name as the indexing service does not like to communicate over a public host name. However this caused a further issue with the service reporting that multiple hosts names could not be run for the service. Fortunately this could be remedied easily by setting the system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled setting to true.

Those were all the steps we needed to take to deploy the site successfully. I’d be interested to hear your experiences if you found any other settings that need to be changed. Feel free to reply in the comments below or contact me directly on twitter @michael_hook.

Comments

Copyright © 2016 - Hook Technologies Ltd - Powered by Octopress