One of the best updates in 7.6 is that the modulesbin and modules directories was moved from vpp folder to the website folder. With this deployment to the cloud or any other server is mutch easier and gives me the felling that I can control all updates from code in a CD-senario.
One thing I woundering of is how database changes are handled when using only nuget-package, since with that, there are no "install/upgrade" on the live server, only deployment of files. Can anyone explain that to me?
There are two scenarios regarding database updates.
1. Development environment
EPiServer.Framework will expose some cmdLets for this. So after you have downloaded one/several packages you can call cmdLet "Update-EPiDatabase" from Package Manager Console. What will happen then is that it will go through all packages and search for sql files in folders <package>\tools\epiupdates and execute the ones it finds (we will have logic in them so if they have already executed nothing happens).
2. Production environment
On your development environment after downloading new packages you can call cmdLet "Export-EPiUpdates". What will happen then is that it will look for sql files as above and collect them and place them in a folder "EPiUpdatePackage" parallell with your site root. You can then copy that folder to your production environment and execute the .bat file it contains (with the path to the site as parameter). it will then execute the scripts on the production server in same manner as when running "Update-EPiDatabase" in your development environment.
Sorry, might be a stupid question now.Does this mean that I must know when to run these powershell cmlLet when I deploy (meaning, should I put it in my Deployment-step in Team City) or does EPiServer handle it automaticly?
Johan correct me if I'm wrong, but I think the decision was that we will not run any cmdLet that modifies the database automatically. The reason for that is that we don't support rollback for the database changes, and we want to give the control to when the database update is done to the developers, so database backups and similar can be done.
If you have updated the package but not run the database updates, you should get a exception during startup that clearly informs of the error.
PerThat sounds like a good decision.Thanks for the explanation!
After the last update, I just got an error in my Package manager console telling me that "There is no 'nuget packages' directory". Web project was put as Default project. I ended up with running the SQL-scripts manually.
Googling that error gave me nothing - any ideas?
Arve, I also get the "there is no nuget packages directory" error. Did you ever solve this?
Nope, not really. Except that in the last patch i added, everything happened all by itself. I have no idea why or what was different from earlier...
If you have your packages folder any other place than just outside your project folder the migrations fail, I fixed it by copying the packages directory from our trunk into the src folder\trunk
copy \trunk\packages to \trunk\src\packages
If i remember correctly they have issued a fix for the problem in one of the latest updates
If that's the case, that it has to be on the same level as the project folders, this must be fixed. Such framework-things should never assume a given structure, as this may vary from vendor to vendor and developer to developer, and even project to project.
Thomas' answer above, as an example: "src" => Source code. Episerver-packages are *not* ones own source code.
I face the same error message with a structure like the following:
I still get the same "There is no 'nuget packages' directory" error.
I noticed there was a bug reported for this earlier, but it was marked as closed in May last year.
Arve, did you find a reasonable workaround?
What version are you on Ted?
I upgraded a projects database as late as today with
a project that has the following structure
without any issues, my project is using version 7.19.1
and I didn't use the hack I described above of copying the packages into src before upgrading
Did you select the web project in the Package Manager Console? I have forgotten that a few times :|
We export the updates and include them in our source. This way the project will auto-update to the latest version in each deploy-environment.
[assembly: WebActivator.PreApplicationStartMethod(typeof(Project.Web.App_Start.EpiDbUp), "Start")]
public class EpiDbUp
public static void Start()
public class EpiDbUpModule
public static void Initialize()
var connectionString = ConfigurationManager.ConnectionStrings["EPiServerDB"].ConnectionString;
var upgrader =
var scripts = upgrader.GetScriptsToExecute().OrderBy(s => GetVersion(s.Name)).ToList();
foreach (var script in scripts)
var sql = DeployChanges.To
var result = sql.PerformUpgrade();
throw new Exception("Failed to upgrade the DB.", result.Error);
// Note: This is not the same as the version number in the database.
private static int GetVersion(string name)
var version = 0;
var match = Regex.Match(name, "([0-9]+).([0-9]+).([0-9]+).sql$");
version += Convert.ToInt32(match.Groups.Value) * 1000;
version += Convert.ToInt32(match.Groups.Value);
I think I'm on to something: The collective "EPiServer.CMS" package cannot be added, as the package "EPiServer.Packaging.UI" fails with the following error:
"Protected modules path can't be found. Check the WebConfig or related connected config file to see if protected modules location is given"
In web.config all I got from the initial install was:
<episerver.packaging protectedVirtualPath="~/path/to/ui/" />
Perhaps that's what causing the EPiServer.Packaging.UI to fail? If I get that one to install, maybe I'll have better luck with the "update-epidatabase" cmdlet.
This is a clean EPiServer 7.5 install, but something must have gone awry at some point. :)
@ted is this the stuff you are missing?In Episerverframework.config<virtualPathProviders> <clear /> <add name="ProtectedAddons" physicalPath="EPiServerModules\Modules" type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider, EPiServer.Framework" /> </virtualPathProviders>
Thanks Tore, but regrettably no - it's in there...
Just did another fresh install through Deployment Center, but EPiServer.Packaging still fails with the same error message. Really odd.
Edit: Tried setting up a new website with the Visual Studio extension instead, but that fails too with the same error ("Protected modules path can't be found..."). Guessing I'm going to have to dive into the install scripts... :)
Edit #2: Ok, so it seems there's a bug in the script causing it to fail if there are certain characters in the path. In this case the folder name C:\Source\Project[EPiServer 7] broke the install script (because of the brackets). Changing the folder name to C:\Source\Project.EPiServer7 resolved the issue. I want my two hours back... :)
This may be a bit off topic from the original question. However, i stumbled in here when I googled the error message "There is no 'nuget packages' directory". It occured after a fresh install of EPiServer Commerce (8.9.0). I found a workaround to this by adding a new nuget.config file in the solution directory with the following content:
<add key="repositoryPath" value="[your-path-to-the-package-folder]" />
Maybe someone will find this information useful.
I came across til problem today, and I couldn't get around it by calling Update-EPiDatabase. However, I noticed in the intellisense that there also was something called:
- and that ran without a hitch. Go figure.
Just my 5 cents,
I ran into the issue "There is no 'nuget packages directory" today when upgrading a 7.5 site to 8.6. I had just taken update all in the nuget manager.
I solved it by undo all the changes and then updated each of the components seperatly. After that i could run Update-EPiDatabase without any trouble.