Hi Craig

Are you using VS2015?

Martin

I did the first part in VS2013 but when it said to restart to complete, I opened it in VS2015. I could reset to the back up and try it all in 2015 I suppose.

Hi Craig

Hmm, ok I went from 7.2.8 to 7.3.0 in VS2015. The only issue I encountered was I needed an untouched dashboard.config. Its a bug thats been fixed in 7.3.1.

You'll need to compare changes to the root web.config and the one in views. Or simply blat them making sure to set the version and connection string.

Other than that my build currently targets 4.5.1.

All converted and worked fine.

M.

Hmmm, I'm a bit confused with the 4.5.1 thing. I'm guessing that's the .NET version and not the MVC version. I want to end up at MVC5. I'll try again in VS2015 right through but if a Nuget Upgrade won't do it then I'll have to do it like this: http://www.attackmonkey.co.uk/blog/2015/10/upgrading-to-73 which is a bit more long winded.

Hi Craig

Yes, .net 4.5.1

Bear in mind MVC4 projects no longer work properly in VS2015. The intellisense is shot to pieces for some reason.

But as 7.3 is MVC5 by default it should automatically convert it all for you when you nuget up.

The improved tooling in VS2015 is reason alone for doing the upgrade!

Good luck

Martin

It's so annoying to see a screen in VS saying "When upgrading your website using NuGet you should answer "No" to the questions to overwrite the Web.config file (and config files in the config folder). " AFTER you upgrade and have answered "Yes" to that question! So now upgrading for a 3rd time :(

Hi Craig

lol yea the config overwrites are quite annoying.

Every time i've done this via nuget, I do compares in WinMerge to ensure important changes are in place.

Still, since version 7. I can safely say doing upgrades is a lot less painful.

Regards M.

Ok, well I put out a separate thread about updating the upgrade documentation. Meanwhile, on the 3rd upgrade, all in VS2015 and selecting "(L) No to All" so the config files aren't overwritten. After a successful build I run it and get a lovely YSOD of:

Could not load file or assembly 'HtmlAgilityPack, Version=1.4.6.0, Culture=neutral, PublicKeyToken=bd319b19eaf3b43a' or one of its dependencies.

Which is not one I was expecting to be honest. So the conundrum is, if I have the original config files in my solution, I have nothing to compare in WinMerge now to see what changes need to be made for the new version.

I think this is a dog's breakfast so I'm going to take a leaf out of Attackmonkey's book and do it his way. More long winded but at least you're more in control: http://www.attackmonkey.co.uk/blog/2015/10/upgrading-to-73

Craig

Craig...

Seriously stick with nuget its awesome! and the best way of doing it in VS.

It's simply just the web.config crapping out because you're trying to run 7.3 on an old config.

Go into the packages folder for your project and you'll find the new ones.

Alternatively just download the full zip file from downloads on our.

M.

This is exactly what I was saying. If you already know about these little things it's fine. But if you don't, it's hours wasted. That's why these nuggets of experience need to be in the documentation. It shouldn't be assumed people know this stuff.

Ok, I'll try one last time using Nuget (fifth attempt now).

Craig

Hi Craig

I'm more a suck it and see person than "read the docs first". Then, ask for help when (and usually) I get stuck LOL!

The problem is there are soooo many ways to configure, manage and extend Umbraco. So the docs can only really cover the basics.

As with all these things, it gets easier with time and experience! :-)

I've been developing on Umbraco for over 5 years since version 4.0.4.2. Its been rocky at times, but i'm glad the company stuck with it. Umbraco is a great product.

Another method (new), which could save even more headaches...Umbraco as a service. It's punted as an easier upgrade pathway.

Regards M.

Hi Martin.

This is a really basic site, nothing fancy in it. I've been webdeving for 19 years and using Umbraco since 4.7.1. It has seriously tried my patience on several occasions in that time.

Fifth upgrade done.

I don't see the config files you mentioned in the solutions packages folder I'm afraid. So I have nothing to compare to. So I'm going to give up with Nuget as a lost cause, install a fresh 7.3.0 project, point it to my database and start importing files and Winmerging config files that DO exist.

6th and hopefully final upgrade attempt about to start! I will report back.

Craig

Hi Craig

So go into the nuget packages folder which will be one level higher than your project..

Go into the UmbracoCms.7.3.0 folder..

Then the UmbracoFiles folder.. here you'll find a complete web.config.

The web.config for views is done as an XSL transform so strip out the XDT crap and you should be good to go.

M.

Hi Martin,

Did as you said and when run got this YSOD:

Could not load file or assembly 'System.Web.Helpers' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Have spent 4 hours on this 5 page site. I could have rebuilt it from scratch in less time. Life's too short, I'm going with AttackMonkey's method.

Thanks for your time.

Craig

And the results are in....

Nuget upgrade x 6 : Null Point in 4 hours.

Integrate old site into fresh install: worked first time in 30 mins.

I know what I'll be doing in future ;)

Hi Craig

Our site is highly complex uses the APIs heavily as well as Umbraco Forms, crosses 4 European projects and one UK site in a single solution.

Nuget the lot of it!

Oh well, its a shame.

Good luck in the future.

M.

I don't have the website in VS unfortunately because it doesn't build (uLocalGovMVC) so manually update each time but the upgrade from 7.2.8 to 7.3.0 has failed completely with the same errors

Could not load types from assembly umbraco, Version=1.0.5750.18164, Culture=neutral, PublicKeyToken=null, errors: Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. File name: 'System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. File name: 'System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. File name: 'System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

would you suggest moving to 7.3.1 even though it's not finished yet?

Hi Steve

When you see those errors, it's almost always web.config fluff ups.

Take the new ones from the umbraco 7.3 zip archive and do a file compare with your current ones and replace any new and modified entries, retaining any custom stuff you've added yourself, including your DB and SMTP entries.

Remember to check the one in the views folder too.

You may need to compare the odd file in the config folder, especially if you have changed them. I have changes in the Examine and Dashboard configs that need to be checked at upgrade time.

Winmerge is a great free tool for doing file compares.

Beyond that, if you're doing a manual upgrade, make sure the libraries in the BIN folder match what's in the zip archive and if you're using any extension packages make sure they're compatible. You must also ensure that any redundant binaries are removed before run your build, as it could cause conflicts.

M.

I should point out our projects started life in Umbraco 4.0.4.2 and doing upgrades (for me at least) have become steadily easier and each time I do, it's taking less time to get to production.

Our main corporate websites are part of a single VS solution and run from one set of controllers, models, views and some legacy XSLT. The binaries are linked at runtime and the common files are served from one set of virtual folders. In the solution are 5 UK and European end points which currently go live via VS/Web deploy. The plan going forward is to add unit testing and continuous integration via a TFS build server.

For example...The time taken to get the solution production ready from 7.2.8 to 7.3.0 has been two weeks. So, this includes TFS branching and merging, nuget solution upgrading, file checking. Running the upgrade and testing the results locally and then on our staging box.

I'm expecting the 5 sites to drop to one week during minor upgrade cycles and back up to two weeks for major.

My recommendation if you're not going the way of UaaS, is use VS/nuget/TFS or Git.

M.

Didn't have time to read everything in this topic but you pointed out a message after upgrading that has been incorrect for a few versions now, so I've just removed it and upgrading to 7.3.1 when it comes out won't show it any more.

https://github.com/umbraco/Umbraco-CMS/commit/7135f9a268f940e887e89dea5de341129cb60bcb

Hi Sebastiaan

I think its fair to say (particularly inexperienced) people are getting confused over the significance of the web.config from build to build. Many don't understand how easily it can change.

Is there any way a transform can be included to overwrite it except the connection string and SMTP settings, at the point of upgrade, by user choice? It would be best for those who don't have lots of custom entries in their web.configs and they can let nuget just get on with it without the worry of whats changed.

For everyone else, N to all

M.

Not sure what you mean?

During upgrade we transform the web.config to add items that are absolutely necessary, remove items that will absolutely conflict and update items that absolutely need a certain value for Umbraco to work.

And just to make it absolutely clear: when you upgrade through NuGet we do our utmost best to make the changes to your config files completely automatically so you should not have to worry about it and about comparing files in merge tools.

You can inspect the transform that is performed for upgrades here if you want: https://github.com/umbraco/Umbraco-CMS/tree/dev-v7/build/NuSpecs/tools

Specifically Web.config.install.xdt is used to transform your web.config.

Also:

For everyone else, N to all

No, it does not matter if you answer yes or no any more. The exact same thing will happen.

Ahhh OK, is this relatively new then?

Previously (not sure from what version its changed) it would simply overwrite what you had, so with past experience I always do a "No to all".

So on 7.3.1 i'll let it do the merge.

I hope it works, may well get it down to a week to production as hoped! Whoop!

Thanks

M.

Sebastiaan

Just to make it clear, will it leave alone any entries you've added to the web.config? Say for the purposes of a package extension or some other custom code?

M.

Yeah, we updated it in 7.2.0 actually to not blindly overwrite stuff any more but obviously I forgot to update the readme file (though the documentation was updated on Our).

It will leave most things alone but some things need to be updated for Umbraco to function. Again, you can inspect exactly what it will update in Web.config.install.xdt and I'm sure you're using source control so you can also inspect changes before you commit them.

Thats great, ok i'll give it a whirl when 7.3.1 lands

M.

Have just tried upgrading a partially complete site from 7.2.8 to 7.3.0 via NuGet in VS2015. Answered "No to all" as advised, built solution then ran up with ctrl+F5. Browser window opens for address

http://localhost:49667/umbraco/AuthorizeUpgrade?redir=%2finstall%2f%3fredir%3dtrue%26url%3dhttp%253a%252f%252flocalhost%253a49667%252f

but hangs forever with just a totally black background and a small Umbraco logo in the top left. I was expecting some leather with a pair of Umbraco earrings to appear. Seems to keep hanging in an odd place.

Any advice appreciated.

So tried again another couple of times with the same result or YSOD if I tried updating stuff in the web.config. In the end what worked was totally replacing the runtime/assemblybinding section of the existing web.config with that from a web.config file from a fresh install. THEN I could look at the earrings while the DB got updated.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <!-- Old asp.net ajax assembly bindings -->
  <dependentAssembly>
    <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>
  <!-- Ensure correct version of MVC -->
  <dependentAssembly>
    <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <!-- Ensure correct version of HtmlAgilityPack -->
  <dependentAssembly>
    <assemblyIdentity name="HtmlAgilityPack" publicKeyToken="bd319b19eaf3b43a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-1.4.6.0" newVersion="1.4.9.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Security.OAuth" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Security.Cookies" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
  </dependentAssembly>
</assemblyBinding>

Hope this helps someone else. However, I haven't finished yet. This is just one step out of a few more I guess.

Sorry Craig, that one is totally on me and that has been fixed for 7.3.1. #h5is!

Hang in there!

Thanks for the 'fess up Sebastiaan ;) One last thing (I hope) is that the Powershell transform misses the new Developer "XML Data Integrity Report" Section as detailed by Jeavon in Zone's London Umbraco Meetup video: https://youtu.be/80P8hZGCAts around minute 52:10 (where he's actually doing a live upgrade of my own site!). The additional step is to add this section into the /Config/Dashboard.config file within the StartupDeveloperDashboardSection section:-

<tab caption="Xml Data Integrity Report">
  <control>
    views/dashboard/developer/xmldataintegrityreport.html
  </control>
</tab>

Hey Craig

Sorry to hear you've had so many issues in (what should be) a simple upgrade. You're not alone on this one, there's been many times where i've literally torn my hair out in exasperation!

At least there's some recognition of the problem and it will be fixed in 7.3.1. I didn't encounter this due to a file compare of my old/new web.configs. Something i've done for many versions. According to Seb, I don't need to do this any more, so on 7.3.1 i'll attempt to ditch it in favour of letting the transform handle things. Fingers crossed!

One thing I have noticed in 7.3 is every time XSLT macros and extensions are invoked, which appears to happen EVERY time a page is called from the server, an INFO is logged, which didn't happen before and is resulting in massive log files. For now i've switched it to WARN as the lowest level.

I've also noticed site memory usage has crept up again, over 1GB for our UK site. Which is a bit poor considering the site is running out of a cache for the most part. We don't hit the backoffice/SQLDB all that often, which is where i'd expect most of the memory consumption to go.

Sebastiaan, any ideas?

M.

I deleted the reference to System.Web.MVC 4.0.0.0 and referenced instead System.Web.MVC 5.3.2.0 which i kept in my bin folder. Didn't help because the reference still pointed to System.Web.MVC 4.0.0.0.

I fussed a bit around and finally checked the path of the reference in the Properties window. It points to .../App_Data/NuGetBackup/20151008-220421/bin/

After I removed System.Web.MVC 4.0.0.0 there and referenced again to System.Web.MVC 5.3.2.0 the error message is gone (respectively replaced by the error message that Newtonsoft.Json has the wrong version, same procedure here ...)

is working on a reply...