How do EPiServer nuget package handle database changes

Vote:
 

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?

#85017
Apr 11, 2014 9:19
Vote:
 

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.

#85020
Apr 11, 2014 10:07
Vote:
 

Thanks Johan.

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?

#85080
Apr 14, 2014 14:44
Vote:
 

Hi

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.

Regards

Per Gunsarfs

#85083
Apr 14, 2014 16:03
Vote:
 

Per
That sounds like a good decision.
Thanks for the explanation!

 

#85085
Apr 14, 2014 16:07
Vote:
 

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?

#86140
May 14, 2014 14:48
Vote:
 

Arve, I also get the "there is no nuget packages directory" error. Did you ever solve this?

#90696
Edited, Sep 16, 2014 12:59
Vote:
 

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...

#90706
Sep 16, 2014 14:44
Vote:
 

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

\trunk\project.sln

\trunk\packages

\trunk\src\project

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

#90733
Edited, Sep 17, 2014 8:40
Vote:
 

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.

#90736
Sep 17, 2014 9:05
Ted
Vote:
 

I face the same error message with a structure like the following:

\MySolution.sln
\packages
\Website\MyProject.csproj

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?

#115734
Jan 16, 2015 19:15
Vote:
 

What version are you on Ted?

I upgraded a projects database as late as today with 

a project that has the following structure

/project.sln

/packages

/src/Website/Website.proj

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 :|

#115735
Edited, Jan 16, 2015 19:27
Vote:
 

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.

  • Use the command Export-EPiUpdates to export the sql files from the nuget package.
  • Add the .sql files with build action Embedded resource to the project.
  • Add the nuget package DbUp to the project
  • Add the code below to automaticly run migrations on startup.
[assembly: WebActivator.PreApplicationStartMethod(typeof(Project.Web.App_Start.EpiDbUp), "Start")]

namespace Project.Web.App_Start
{
    public class EpiDbUp
    {
        public static void Start()
        {
            EpiDbUpModule.Initialize();
        }
    }
}



public class EpiDbUpModule
    {
        public static void Initialize()
        {
            var connectionString = ConfigurationManager.ConnectionStrings["EPiServerDB"].ConnectionString;

            var upgrader =
                DeployChanges.To
                    .SqlDatabase(connectionString)
                    .WithScriptsEmbeddedInAssembly(Assembly.GetExecutingAssembly())
                    .LogScriptOutput()
                    .Build();

            var scripts = upgrader.GetScriptsToExecute().OrderBy(s => GetVersion(s.Name)).ToList();

            foreach (var script in scripts)
            {
                var sql = DeployChanges.To
                    .SqlDatabase(connectionString)
                    .WithScript(script)
                    .LogScriptOutput()
                    .Build();

                if (sql.IsUpgradeRequired())
                {
                    var result = sql.PerformUpgrade();

                    if (!result.Successful)
                    {
                        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[1].Value) * 1000;
            version += Convert.ToInt32(match.Groups[2].Value);
            return version;
        }
    }



#115775
Edited, Jan 19, 2015 11:27
Ted
Vote:
 

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. :)

#115804
Jan 19, 2015 13:36
Vote:
 

@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>

#115806
Jan 19, 2015 13:39
Ted
Vote:
 

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... :)

#115811
Edited, Jan 19, 2015 13:58
Vote:
 

Hi,

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:

<settings>
    <add key="repositoryPath" value="[your-path-to-the-package-folder]" />
</settings>

Maybe someone will find this information useful.

#119093
Edited, Mar 20, 2015 15:09
Vote:
 

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:

upgrade\Update-EPiDatabase

 - and that ran without a hitch. Go figure. 

#119439
Mar 27, 2015 16:16
Vote:
 

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. 

#121972
May 22, 2015 13:43
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.