I am still in the process of trying to upgrade our Umbraco platform from 4.7.2 to a newer version 7. So far it's been a nightmare and unsuccessful so I am rolling things back and starting over. I've seen varying opinions on different posts and links...so here's my questions on the hurdles I've run into so far...
First, let me describe our architecture.....we have 2 umbraco web servers but they point to a universal file share on a SQL machine, where the Umbraco database also resides. So all they do is IIS. We have the 2 web servers in the distributed call section of the UmbracoSettings.config file. From my rough understanding there is some caching that gets placed on each server.
That being said...here are my questions before I attempt this upgrade again...
1) Do we need to worry about (delete, copy, etc....) and of these app_data folders on the WEB servers? Again, my understanding is they are cache files....
2) I've seen posts that say you should copy over (merge) the new \config folder from the upgrade. The umbraco instructions don't mention this but imply more of a leave the current config and review, merge the differences. There are 22 files in the config folder. I don't know what all of the changes are or could be but trying to accurately review and merge 22 of them with the previous config files accurately is a recipe for issues and pretty sure this is where we are having issues. Keep in mind I am going from 4.7.2 to a newer version 7. There is no hopping there in one hop and more likely at least 7-10 separate upgrades. 22 file reviews/merges x 10 upgrades is going to be brutal. Please let me know the best practice and how we should approach this to make it more consistent. Doing this in a QA environment is one thing, but we have to have a good, consistent process for doing this in production environment.
I would recommend performing this upgrade on your local, then overwriting the production files/database with that upgraded version. That way, you don't run into issues of caching/sharing across multiple servers.
I don't know what you mean by "10 upgrades". You just have one website, right? Why would you need to perform 10 upgrades? If you are attempting to upgrade from version to version from 4.7.2 to 7.4.3, don't. You should be able to directly upgrade to 7.4.3.
Regarding merges, I recommend comparing your upgraded files to a new install of Umbraco 7.4.3. If there is a difference that is unimportant, favor the version of the file that belongs to a clean 7.4.3 version of Umbraco. Also, use a tool like WinMerge that allows you to ignore things like whitespace differences.
Also, regarding the distributed caching. The latest version of Umbraco (7.4.3) has a new mechanism to handle caching across multiple servers. It's called flexible load balancing. This means that you no longer need to specify each server in your umbracoSettings.config file (if you still have that info in there, you may want to remove it). See here for more info: https://our.umbraco.org/documentation/getting-started/setup/server-setup/load-balancing/flexible
Thanks Nicholas. Correct, we just have one website. I like your reply but it goes against everything I've read in that you have to do a series of updates and can't go directly from 4.7.2 to any version of 7. Even Umbraco notes on this site seem to imply that is a requirement. Do you or anyone else know of any upgrade notes going directly from 4.7.2 to 7.4.3. I would love to be able to do it that way and I am sure it would save me tons of time and headaches.
So with our current architecture of IIS on 2 boxes that point to the file share on a separate server......what files are actually needed on those web servers, if any? Again, I know at one point some app_data caching was needed. Our site is also protected by SiteMinder so I know those files need to stay. Just curious on what other folders/files need to be on the web servers themselves with our topology. From my recollection we've never updated any files there when we did upgrades....upgrades files seem to be updated only on our file share where IIS is pointing (non web boxes).
Thanks for any further clarification you can provide....
You should be able to go directly from 4.7.2 to 7.4.3. For the most part you should be able to follow the general upgrade guide. You should also refer to the version-specific upgrade guide for your specific version (i.e., 4.7.2). I'm not sure if you should or should not refer to the notes for the intermediate versions (i.e., those listed between 4.7.2 and 7.4.3), but probably best to at least give them a look to avoid any issues. Regardless, you should not actually upgrade specifically to intermediate versions (i.e., you should upgrade directly to the latest version, potentially following version-specific instructions as well).
The only thing I can think of that would require the file share would be media in the media folder. If you have any plugins that change files, those too may need to be on a file share (as an example, Formulate would require the App_Data/Formulate folder to be on a file share, and Contour has an upload folder you'd need to add to the file share).
Thanks sir...I will attempt this and see what happens. It would be awesome if it works this way. And yes, I will look at the individual update notes to remove any files no longer needed, etc... if this works I'll come back and post results and make sure the post gets marked as solution. I do appreciate your time and input and your speedy replies.
I have the files in place and removed all the files in the specific upgrade list and merged what appeared to be the necessary pieces. I actually merged my web.config pieces into the 7.2.7 out of the box web.config. There are a lot of differences but think I have them all. I am going to 7.2.7 first just because it is the last version that doesn't have the new load balancing in it and just want to get it working to this version first. However, I am getting an error when I browse my site to do the upgrade. Has anyone seen this one or have an idea?
Could not load types from assembly Governor.Umbraco.FullTextSearch, Version=4.7.2.0, Culture=neutral, PublicKeyToken=null, errors:
Exception: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null'
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.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null'
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.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null'
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].
Also, my web.config from 4.7.2 has the database connection listed as a key in the appSettings section. I copied that to the new web.config but noticed that in version 7 it mentions it needs to be in the 'connection string section. Is that correct and I shouldn't copy it into the appSettings in the upgraded web.config? If that is correct, what is the value is expecting for 'provider name"?
Thanks for the reply Nicholas. Can you give me more detail on exactly how to add the assembly? What line would I insert into the web.config?
I've found a few articles on the Lucene/assembly issue. One suggested to remove it from the GAC and try again (but on a Windows 2012 server this doesn't seem to be as obvious where it is as a non-server machine, from what I am seeing) and when I did a scan of the c:\windows\assembly folder it found nothing on Lucene..
I also found a couple of articles that seem to refer to my situation, however, I don't see a real fix so other than your suggestion (that I could use some assistance on), the only thing I can think of is to roll my environment back, remove the fulltext package and then try the upgrade again. Let me know if that sounds like the correct direction if the assembly addition to the web.config doesn't work.
This basically tells the website "if you see this old version of this DLL requested, use this new particular version instead".
By the way, no need to roll back the environment to remove the full text package (if you decide to go that route). That may be as simple as removing the full text DLL(s) from the bin folder (and perhaps removing it from another place or two, such as on your search results page).
But the result seemed to be the same (even after resetting IIS). Even after changing it to something like....
the error referred to version 2.9.2.2, which was the old version of the file. This tells me something (like GAC) still sees that version...no clue where it is because I can't find it when searching the assembly folder for 'lucene" or the publicKey Token number, so not sure how to remove the old version reference. Just know an upgrade shouldn't be nearly this painful.
When you say to just remove the full text .dlls are you just referring to the lucenexxx.dll(s) and the xml for that? If so, that attempt failed too, so please let me know if there are other full text dlls I need to remove.
I just turned on the assembly binding logging and got a bit more of an error.....is it possible (or good practice) to remove the ASP temp folder it's complaining about?
LOG: This bind starts in default load context.
LOG: Using application configuration file: \qasqlumb1\umbraco\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Lucene.Net, Version=2.9.4.1, Culture=neutral, PublicKeyToken=85089178b9ac3181
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/b31c2acf/4d2c174/Lucene.Net.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/b31c2acf/4d2c174/Lucene.Net/Lucene.Net.DLL.
LOG: Attempting download of new URL file://qasqlumb1/umbraco/bin/Lucene.Net.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Exception: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.4.1, Culture=neutral, PublicKeyToken=85089178b9ac3181' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Lucene.Net, Version=2.9.4.1, Culture=neutral, PublicKeyToken=85089178b9ac3181'
I've heard of people clearing the temporary ASP.NET files, but I'm not sure how to do that (maybe Google it before deleting those files to see if there is a standard/safe way of doing that).
Also, note that the assembly bindings contain the public key token for the DLL. You might want to check the old DLL and the new DLL for Lucene to ensure they both have the same public key token. Again, I've never done this, but there is apparently an easy way to do it: http://dotbert.loedeman.nl/how-to-find-public-key-token-for-a-net-dll-or-assembly/
It could also be that the old DLL is just incompatible with the new version of the DLL (i.e., the function signatures and classes and so on are different). In that case, you could either remove the plugin (i.e., delete its DLL's), attempt to upgrade the plugin, or get the source code of the plugin and build it against the new Lucene DLL's.
You might also check the forum for the plugin to see if anybody else has come across this issue and has a solution.
No, I would not remove the Lucene DLL's, as those are used by Umbraco.
While I've never used that plugin, I imagine the DLL would be called something like "Governor.Umbraco.FullTextSearch.dll" (based on the error message you pasted above).
If you want to see exactly which DLL's are not part of a base Umbraco install (i.e., ones that belong to a plugin), you can install a new Umbraco website from scratch separately, then use a tool like WinMerge to compare that install and the one you are attempting to upgrade.
By the way, if you assembly binding doesn't seem to be working, you might try turning on assembling binding logging. I haven't tried that myself, but your error messages indicated that you could try that.
Thanks for the suggestions Nicholas. I'll look into these options and try a few things and post back. Much appreciate the assistance and suggestions....
Upgrade Question
I am still in the process of trying to upgrade our Umbraco platform from 4.7.2 to a newer version 7. So far it's been a nightmare and unsuccessful so I am rolling things back and starting over. I've seen varying opinions on different posts and links...so here's my questions on the hurdles I've run into so far...
First, let me describe our architecture.....we have 2 umbraco web servers but they point to a universal file share on a SQL machine, where the Umbraco database also resides. So all they do is IIS. We have the 2 web servers in the distributed call section of the UmbracoSettings.config file. From my rough understanding there is some caching that gets placed on each server.
That being said...here are my questions before I attempt this upgrade again...
1) Do we need to worry about (delete, copy, etc....) and of these app_data folders on the WEB servers? Again, my understanding is they are cache files....
2) I've seen posts that say you should copy over (merge) the new \config folder from the upgrade. The umbraco instructions don't mention this but imply more of a leave the current config and review, merge the differences. There are 22 files in the config folder. I don't know what all of the changes are or could be but trying to accurately review and merge 22 of them with the previous config files accurately is a recipe for issues and pretty sure this is where we are having issues. Keep in mind I am going from 4.7.2 to a newer version 7. There is no hopping there in one hop and more likely at least 7-10 separate upgrades. 22 file reviews/merges x 10 upgrades is going to be brutal. Please let me know the best practice and how we should approach this to make it more consistent. Doing this in a QA environment is one thing, but we have to have a good, consistent process for doing this in production environment.
Thanks!!
I would recommend performing this upgrade on your local, then overwriting the production files/database with that upgraded version. That way, you don't run into issues of caching/sharing across multiple servers.
I don't know what you mean by "10 upgrades". You just have one website, right? Why would you need to perform 10 upgrades? If you are attempting to upgrade from version to version from 4.7.2 to 7.4.3, don't. You should be able to directly upgrade to 7.4.3.
Regarding merges, I recommend comparing your upgraded files to a new install of Umbraco 7.4.3. If there is a difference that is unimportant, favor the version of the file that belongs to a clean 7.4.3 version of Umbraco. Also, use a tool like WinMerge that allows you to ignore things like whitespace differences.
Also, regarding the distributed caching. The latest version of Umbraco (7.4.3) has a new mechanism to handle caching across multiple servers. It's called flexible load balancing. This means that you no longer need to specify each server in your umbracoSettings.config file (if you still have that info in there, you may want to remove it). See here for more info: https://our.umbraco.org/documentation/getting-started/setup/server-setup/load-balancing/flexible
Thanks Nicholas. Correct, we just have one website. I like your reply but it goes against everything I've read in that you have to do a series of updates and can't go directly from 4.7.2 to any version of 7. Even Umbraco notes on this site seem to imply that is a requirement. Do you or anyone else know of any upgrade notes going directly from 4.7.2 to 7.4.3. I would love to be able to do it that way and I am sure it would save me tons of time and headaches.
So with our current architecture of IIS on 2 boxes that point to the file share on a separate server......what files are actually needed on those web servers, if any? Again, I know at one point some app_data caching was needed. Our site is also protected by SiteMinder so I know those files need to stay. Just curious on what other folders/files need to be on the web servers themselves with our topology. From my recollection we've never updated any files there when we did upgrades....upgrades files seem to be updated only on our file share where IIS is pointing (non web boxes).
Thanks for any further clarification you can provide....
You should be able to go directly from 4.7.2 to 7.4.3. For the most part you should be able to follow the general upgrade guide. You should also refer to the version-specific upgrade guide for your specific version (i.e., 4.7.2). I'm not sure if you should or should not refer to the notes for the intermediate versions (i.e., those listed between 4.7.2 and 7.4.3), but probably best to at least give them a look to avoid any issues. Regardless, you should not actually upgrade specifically to intermediate versions (i.e., you should upgrade directly to the latest version, potentially following version-specific instructions as well).
The only thing I can think of that would require the file share would be media in the media folder. If you have any plugins that change files, those too may need to be on a file share (as an example, Formulate would require the
App_Data/Formulatefolder to be on a file share, and Contour has an upload folder you'd need to add to the file share).Thanks sir...I will attempt this and see what happens. It would be awesome if it works this way. And yes, I will look at the individual update notes to remove any files no longer needed, etc... if this works I'll come back and post results and make sure the post gets marked as solution. I do appreciate your time and input and your speedy replies.
Thanks!
I have the files in place and removed all the files in the specific upgrade list and merged what appeared to be the necessary pieces. I actually merged my web.config pieces into the 7.2.7 out of the box web.config. There are a lot of differences but think I have them all. I am going to 7.2.7 first just because it is the last version that doesn't have the new load balancing in it and just want to get it working to this version first. However, I am getting an error when I browse my site to do the upgrade. Has anyone seen this one or have an idea?
Could not load types from assembly Governor.Umbraco.FullTextSearch, Version=4.7.2.0, Culture=neutral, PublicKeyToken=null, errors: Exception: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null'
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.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null'
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.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'Lucene.Net, Version=2.9.2.2, Culture=neutral, PublicKeyToken=null'
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].
Also, my web.config from 4.7.2 has the database connection listed as a key in the appSettings section. I copied that to the new web.config but noticed that in version 7 it mentions it needs to be in the 'connection string section. Is that correct and I shouldn't copy it into the appSettings in the upgraded web.config? If that is correct, what is the value is expecting for 'provider name"?
Looks like you are using this plugin: https://our.umbraco.org/projects/website-utilities/full-text-search
I am unsure if it requires a specific version of Examine/Lucene, but your errors imply that may be what's going on.
You can usually solve that with an assembly binding in your web.config.
Thanks for the reply Nicholas. Can you give me more detail on exactly how to add the assembly? What line would I insert into the web.config?
I've found a few articles on the Lucene/assembly issue. One suggested to remove it from the GAC and try again (but on a Windows 2012 server this doesn't seem to be as obvious where it is as a non-server machine, from what I am seeing) and when I did a scan of the c:\windows\assembly folder it found nothing on Lucene..
I also found a couple of articles that seem to refer to my situation, however, I don't see a real fix so other than your suggestion (that I could use some assistance on), the only thing I can think of is to roll my environment back, remove the fulltext package and then try the upgrade again. Let me know if that sounds like the correct direction if the assembly addition to the web.config doesn't work.
http://stackoverflow.com/questions/10297961/c-could-not-load-types-from-assembly (from this article - I checked and did not have anything in my app_plugins folder).
Thanks
Here's an example of the assembly bindings from one of my web.configs:
This basically tells the website "if you see this old version of this DLL requested, use this new particular version instead".
By the way, no need to roll back the environment to remove the full text package (if you decide to go that route). That may be as simple as removing the full text DLL(s) from the bin folder (and perhaps removing it from another place or two, such as on your search results page).
Thanks again Nicholas. I tried adding this to my web.config...
But the result seemed to be the same (even after resetting IIS). Even after changing it to something like....
the error referred to version 2.9.2.2, which was the old version of the file. This tells me something (like GAC) still sees that version...no clue where it is because I can't find it when searching the assembly folder for 'lucene" or the publicKey Token number, so not sure how to remove the old version reference. Just know an upgrade shouldn't be nearly this painful.
When you say to just remove the full text .dlls are you just referring to the lucenexxx.dll(s) and the xml for that? If so, that attempt failed too, so please let me know if there are other full text dlls I need to remove.
Thanks
I just turned on the assembly binding logging and got a bit more of an error.....is it possible (or good practice) to remove the ASP temp folder it's complaining about?
=== Pre-bind state information === LOG: DisplayName = Lucene.Net, Version=2.9.4.1, Culture=neutral, PublicKeyToken=85089178b9ac3181 (Fully-specified) LOG: Appbase = file://qasqlumb1/umbraco/ LOG: Initial PrivatePath = \qasqlumb1\umbraco\bin
Calling assembly : UmbracoExamine, Version=0.7.0.21653, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context. LOG: Using application configuration file: \qasqlumb1\umbraco\web.config LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Post-policy reference: Lucene.Net, Version=2.9.4.1, Culture=neutral, PublicKeyToken=85089178b9ac3181 LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/b31c2acf/4d2c174/Lucene.Net.DLL. LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/b31c2acf/4d2c174/Lucene.Net/Lucene.Net.DLL. LOG: Attempting download of new URL file://qasqlumb1/umbraco/bin/Lucene.Net.DLL. WRN: Comparing the assembly name resulted in the mismatch: Revision Number ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Exception: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.9.4.1, Culture=neutral, PublicKeyToken=85089178b9ac3181' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'Lucene.Net, Version=2.9.4.1, Culture=neutral, PublicKeyToken=85089178b9ac3181'
I've heard of people clearing the temporary ASP.NET files, but I'm not sure how to do that (maybe Google it before deleting those files to see if there is a standard/safe way of doing that).
Also, note that the assembly bindings contain the public key token for the DLL. You might want to check the old DLL and the new DLL for Lucene to ensure they both have the same public key token. Again, I've never done this, but there is apparently an easy way to do it: http://dotbert.loedeman.nl/how-to-find-public-key-token-for-a-net-dll-or-assembly/
It could also be that the old DLL is just incompatible with the new version of the DLL (i.e., the function signatures and classes and so on are different). In that case, you could either remove the plugin (i.e., delete its DLL's), attempt to upgrade the plugin, or get the source code of the plugin and build it against the new Lucene DLL's.
You might also check the forum for the plugin to see if anybody else has come across this issue and has a solution.
No, I would not remove the Lucene DLL's, as those are used by Umbraco.
While I've never used that plugin, I imagine the DLL would be called something like "Governor.Umbraco.FullTextSearch.dll" (based on the error message you pasted above).
If you want to see exactly which DLL's are not part of a base Umbraco install (i.e., ones that belong to a plugin), you can install a new Umbraco website from scratch separately, then use a tool like WinMerge to compare that install and the one you are attempting to upgrade.
By the way, if you assembly binding doesn't seem to be working, you might try turning on assembling binding logging. I haven't tried that myself, but your error messages indicated that you could try that.
Thanks for the suggestions Nicholas. I'll look into these options and try a few things and post back. Much appreciate the assistance and suggestions....
is working on a reply...