I am trying to upgrade the site from v 7.6 to v. 7.15.1.
I have done the upgrade on localhost which included updating the db.
Now I transferred my files from localhost o the test site and on there I am getting an error in log:
ERROR Umbraco.Core.UmbracoApplicationBase - An unhandled exception occurred
System.Data.SqlClient.SqlException (0x80131904): Invalid object name 'umbracoUserLogin'.
and I can't login to the backoffice.
It seems to be looking for umbracoUserLogin on test while it doesn't exist yet because on test the db is not updated yet.
How to update the db on test in this case while the files have already been updated on localhost and transferred to test site?
I have done 2 umbraco upgrades recently; one is from 7.5.7 to 7.13.1 and the recent one is from 7.13.1 to 7.15.1.
During my upgrade; I have seen this problem and fix in this issue can help you for your problem(and I didn't see this problem again after doing the upgrade again, but this time checking all the auto changing files and accepting them one at a time-see details below for this) but coming back to your question; "What's the best way to upgrade from umbraco 7.6 to 7.15.1(including db upgrade)"; here are the steps that you should follow;
Create a backup for your project and your umbraco db before you start. If you are using Git, then things will be super easy for this.
Open up Nuget Package Manager for your Umbraco project and do the package upgrade using the Nuget Package Manger window or the consol. Search for UmbracoCms version 7.15.1 for your case.
Once you start doing the upgrade, you will see some popup windows that will ask you to approve some auto file changes(including some config files changes). As you don't want to lose some of your pre-upgrade settings, don't accept them all or discard them all, check all of them one by one, and as a general rule; if you don't have any custom changes for those files, then simply approve the change, otherwise, check your changes and make sure you don't loose anything and discard some of these file changes as a result.
Once you're done with your UmbracoCms upgrade(which will automatically do some dependency package upgrades), build your project, make sure all is looking good then go to your local project's umbraco back-office url, this will trigger the rest of the umbraco upgrade process and simply complete the upgrade steps by following the screens- at this point your umbraco db changes will be done automatically and it is possible that you might have some issues with some old corrupt cached files, if this happens, then simply delete App_Data/TEMP files and App_Data umbraco.config file and try again. If you see some other problems during the installation, check the logs(browser developer tools can be handy to understand the problems in this case), and fix them one at a time. It is possible that you don'T need some of your old web.config settings and they might cause some issues, simply comment out those lines and see if this will fix some of the issues.
Once you are done with you local upgrade, deploy your code to your testing environment, and go to the umbraco url of your test environment and follow the screens to complete the installation for your testing environment. If you see any problems, please check my notes for step 4 above.
Do your umbraco upgrade for other testing environments(QA, UAT, Training etc) and complete your umbraco upgrade tests. Once the tests are done, then you are ready to go live. After the live deployment, you will have to complete the umbraco upgrade one last time, but this time for the live system.
Always get your back-ups for each environment before you do the upgrade, so you will be ready to rollback your changes if things go wrong(which might happen as you're doing a big umbraco upgrade).
Final note; there are some good articles for this, please take a look to understand the process better. Good luck!
Related
I am very new to EntityFramework development, not to mention to .NetCore and MVC design pattern, I actually started with .NetCore development with a introduction book to those subjects, I reached a chapter where the autor starts with an MVC project (still using .NetCore 2.0) and do Scaffolding to create the EF model based on a Database previously created, then he jumps to add a controller via wizard, chosing the option that says: "MVC Controller with views, using Entity Framework", but when I do this, a get the error:
"There was an error running the selected code generator: ' Failed to
update dependency information for the project. Please restore the
project and try again."
I tried adding this files manually and detected that this happens when I try (or the wizard tries) to create the view file, either using an empty template or using one of the models, the result is the same.
I thought it was for the NuGet packages that where "asking" for updates, so I updated them, but nothing changed, I recreated the project several times, trying to leave the NuGet packages versions that the autor mentions to install, and to have "everything up to date" but still got the same.
I found another question in here with the same problem, and tried the possible solutions that mentions there, but none worked for me, I even try to install the versions 2.0.0 (or the lowest if there where no version 2.0.0) of the NuGet packages needed (or rather, mentioned by the author), and there was a change, still an error, but a different one, that says that the Microsoft.AspNetCore.Razor.Design.targets file needs a value on Configuration...?, still not know what to do, I noticed that updating 3 packages eliminates this error but is going back to the views error.
I don't know what else can I do or how to address this problem.
I finally made it work, although at the end, I don't know what was the problem, what I did was to uninstall all the NuGet packages, then reinstall one by one, chosing the 2.0.0 versions of each one (or the lowest if there was no 2.0.0 version) until there where no sintax errors (by the way, I already had done this, but I don't know what changed) and ended up with 13 packages installed, after verifying that the project builds correctly, I tried again to add via wizard the controller and the view and it threw another error asking to update just two packages (EntityFrameworkcore and EntityFrameworkCore.Design) to versions 2.0.3, after that, I was able to add both the controller and the views with no problem at all and the project still builds correctly.
Using a powershell script to deploy a CRM Package works well, but I am running into some unexpected behavior.
The package has 1 unmanaged solution that it uploads. It works perfectly if the solution does not exist on the target CRM organization. However, if the solution does already exist on the organization and I try to deploy it again with some changes, it will not work. The changes are not uploaded and I do not get any errors.
If I change the version number in the solution (from 0.0.1 to 0.0.2, for example) then uploading it works as expected.
I would rather not change the version every time though, and since manually uploading an unmanaged solution with the same version number works perfectly I would expect the script to be able to do it as well.
I tried using the CRM Package Deployer method of importing a package to see if it would work as I expect or if it would show any error messages.
It's messages show:
Skipping solution MySolution. Version 0.0.2 of the solution is already loaded.
So it appears that if a solution with the same name and version number exists in the organization then it will be skipped entirely. This is sort of unfortunate.
It seems I'll have to implement a workaround. I see two options:
The DeployPackage script deletes the solution in the target CRM organization (if it exists) before attempting to upload.
My ExportSolution script changes the version number every time it runs.
I am in the middle of rebuilding my VPS and I am getting an error in WHM.
CENTOS 6.5 x86_64 virtuozzo – vps-1......... WHM 11.34.2 (build 8)
Reasons for blocked updates
Please correct these issues and rerun updates.
fatal: Upgrade is blocked because EXIMUP is set to 'never' in your configuration. To proceed, you can touch file '/var/cpanel/exim.unmanaged' and run the upgrade one more time. Please refer to our documentation at http://go.cpanel.net/1136UpgradeExim for more information.
The URL for help doesn't exist.
I do not see this file in when I check for it.
I found the Exim Configuration Manager but do not see anything that matches what the error states.
I have a feeling this is fairly easy fix but I am far from an expert on VPS managing. I'm learning the hard way to put it nicely...
Does anyone know how I can clear this out so I can upgrade WHM?
I see in their documentation:
To upgrade from cPanel & WHM version 11.34 and earlier:
Touch /var/cpanel/exim.unmanaged
Run the upgrade again.
What does "Touch"mean? I tried toggling the exim option in preferences but it made no difference.
After a night of fighting this I find the answer right after I post. Here is how I solved it.
Touch means to create or modify a file without actually writing to it. So in this case since the file did not exist. I created a new file in /var/cpanel/ called 'exim.unmanaged'
After placing that file in the directory I ran the updates again and it is now upgrading WHM and cPanel.
Pros know this I am sure but hopefully this will be helpful for newbi VPS admins like myself.
I'm part of a development team that works on many CMS based projects, using systems like Joomla and Drupal.
In our development process, all of our code changes are managed inside of Git. At the end of a sprint, we create a DIFF that we can apply via patch to live site.
The problem is that most of the time, the changes include
Database Schema Changes
Database Data Changes
Source Code changes
Binary file changes (like images)
Git Diff handles Source Code changes beautifully. Binary files are only not included in the Diff except for reference to the fact that the files have changed.
Database Schema Changes and Database Data Changes are a mess.
I was wandering if anything like an unified patch system exists that could be used to deploy all of these changes in 1 patch.
So the question is, "Is there a system that can be used to deploy all of these changes in 1 shot?
Ideally, this system would allow to run dry-run like patch, but for all of the 4 data types.
Edit:
Thank you everyone for the feedback that you provided, it was a starting point for my research in this area.
Here is what I found so far:
It's difficult to deploy php based
applications using linux packaging
system because the changes to the
project happen iteratively rather
then as releases.
It would be possible to use dbconfig to deploy changes to a
project, but the problem is
generating mysql db diffs (schema
and data)
what really is missing for deployment of php based applications
is a deployment manager that would
be installed on the server and would
be the interface for deploying the
patches
I started a Google Wave on this topic and produced a lot of information as a result.
If anyone is interested in reading this wave, please let me know and I will add you.
For handling installation and upgrade of our application, we use the debian packaging system . ( .deb package )
Context :
We are making J2EE + Flex application. Shipping and administred throught a VPN.
So not so far from you.
Fresh install and upgrade for a version to another are made through puppet ( a system for automating system administration tasks : he install our .deb )
In the .deb we have
our compiled sourcecode
the schema of the database ( handled by [db-config][1] )
binary stuff
how to install throught apt all other application needed ( mysql, tomcat ... )
= All stuff for a fresh install
We also add the info to go from a version to another
the script for upgrading the database ( for each version )
new binary
new stuff to lauch at the machine start ( eg : some weeks ago we have add a activeMQ server )
=> Once the .deb is made correctly, we can install or upgrade seamless in one operation. ( it's made automatically, without any prompt ).
Theire is one .deb per realease, each .deb has a version number and a signature.
You can pick any of our .deb and make a fresh install or upgrade from the actual version to the version number he hold.
The .deb is in our continous integration system. ( we build a .deb each hour, like if we are about to realease a new version )
What are the benefit ?
Install / upgrade automaticcally, with confidence.
Rollback a version
run dry are natively supported
In your precise case
* Database Schema Changes
* Database Data Changes
* Source Code changes
* Binary file changes (like images)
Database => you will have to write migration script. One for each version. ( ex : 1.2-update.sql 1.3-update.sql )
Source code and binary => add them, say in witch version they have to be copied/use
Edit : i'm not sure about source code. We are doing that with compiled code...
Some links to start :
https://wiki.ubuntu.com/PackagingGuide/Complete
http://www.debian.org/doc/manuals/maint-guide/index.fr.html#contents ( in french )
[1]: http://pwet.fr/man/linux/formats/dbconfig dbconfig
[1]: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html debian
I don't think you'll find a fail-safe mechanism.
I recommend that, when possible, you take into account compatibility with the current published source when making schema/data changes.
This way you can make a v. simple tool that runs database scripts committed to a particular svn location (you don't want diff on database changes, as if you need further modifications you need different statements).
With the above done, you can have a simple command that runs the database changes, then the binary & source code changes.
For database there is also the option of schema&data comparisons tools, these could be used to compare environments & make sure there isn't anything unexpected missing in the change scripts - could also generate the change scripts, but as I said you really want to make sure it won't break current source.
You can create a tool to do the migrations painlessly -- something similar to Peoplesoft's Patch Upgrade Assistant.
It is basically a standalone executable that reads an "Upgrade Template" and carries out tasks. The upgrade template declaratively describes the upgrade tasks or "steps". The steps could be - copy (for backing up or moving the precompiled objects like classes and othar binaries), database (for altering schema elements), SQL Scripts (for loading or transforming current data). The steps will have some predicate logic capable - if it is this, do this, else skip it and go to next etc.
The template is usually an XML file. It also provides for manual steps with instructions for manual actions. Each step also specifies if it is recoverable or not. It would also validate if the step has succeeded or not.
It may be possible to have a Open Source project around this requirement which is quite common.
You need to save git commit objects in local file and then import them into other repo/branch.
I have taken the org.eclipse.equinox.p2.examples.rcp.prestartupdate project and adapted it for use in my RCP application. I then setup an update repository that gets updated as part of my nightly build.
When I open my application it goes through the motions like it is updating - it finds the update site, generates an uninstall and install operand for each bundle correctly and says that it finished with no errors. The problem is that the plugins never actually get installed in the plugins folder even though the profile gets updated (a subsequent run states there are no updates). Next time my build runs it correctly identifies there are updates, but the same thing happens again.
I have spent days debugging and the only thing that looks out of the ordinary (not that I fully understand what is going on) is that during the final configure phase none of the TouchpointData objects have any instructions so it doesn't look like configure is doing what it should.
I really have no clue where to look next and would like to see if anyone else has any ideas.
Update:
I finally figured out what was going on.
The problem started when I built my product without the generating the metadata repository. When building through Eclipse I didn't check the "Generate metadata repository" in the export product wizards because I didn't need a p2 repository, just the product. The problem is that without checking that button the product does not install as P2 enabled causing side effects such as not generating a profile among other things.
I tried to compensate for this by manually creating a profile in code which I have since found out is a really bad idea. My original problems were created because my profile wasn't set up correctly.
Once I started exporting the product with "Generate metadata repository" checked the update started correctly installing the new plugins.
The problem I have now is that although the plugins are being installed correctly, the executable is getting trashed and I cannot launch my application any more. I am building my update site through Hudson and the binary folder which is present when I use the Eclipse Export Product wizard is missing. I am assuming that is what is going wrong now.
Any ideas why the binaries would not be building in my headless PDE build?
Figured this out also. I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.
I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.