Hello,
Today I compared a fresh new DNN 9.13.04 install with my current production installation (that has been updated during years). I discovered that I had an old Newtonsoft.json.dll (that I copied in production installaiton). I have also seen that there are some dll, in production environment, that there are not in fresh new install of 9.13.04.
They are:
Dnn.Modules.ModuleCreator.dll DotNetNuke.Website.dll.config DotNetNuke.Providers.FiftyOneClientCapabilityProvider.dll FiftyOne.Foundation.dll
Are these old dll that can I safely delete? Thanks!
It's difficult to say. If you have any third party modules using them, no it's not safe. As a policy we leave old assemblies unless they are causing a problem. We prefer the method of a complete DNN rebuild, even in cases where large data needs to be migrated. This method ensures we have a clean base and we can continue to support the client.
EDIT: Of course by "complete DNN rebuld", I mean only to old installations that we have very old legacy assemblies in it and the client wants an upgrade. The upgrade path of DNN is excellent and is the best way to keep safe.
Hello, I have only modules developed by myself.
I found that DotNetNuke.Providers.FiftyOneClientCapabilityProvider.dll and FiftyOne.Foundation.dll that are related to DotNetNuke Client Capability Provider v9.1.0 that I think has been replaced by DotNetNuke ASP.NET Client Capability Provider v9.13.4.
Do you know how to remove the old DotNetNuke Client Capability Provider v9.1.0? The remove button is not visible...
Thanks
Posted By fabl on 10/15/2024 3:51 AM Hello, Today I compared a fresh new DNN 9.13.04 install with my current production installation (that has been updated during years). I discovered that I had an old Newtonsoft.json.dll (that I copied in production installaiton). I have also seen that there are some dll, in production environment, that there are not in fresh new install of 9.13.04. They are: Dnn.Modules.ModuleCreator.dll DotNetNuke.Website.dll.config DotNetNuke.Providers.FiftyOneClientCapabilityProvider.dll FiftyOne.Foundation.dll Are these old dll that can I safely delete? Thanks!
Hello!
This thread is a great reminder of why I've developed the upgrade process we use over time. It's very important on every upgrade to keep things as tidy as possible, for all of the reasons: ease of ongoing maintenance, limiting experiencing new bugs, easier troubleshooting in the future, security, etc. In short, you should keep your website as clean and clear as possible of anything it doesn't need. Otherwise, you're going to remain in a never-ending loop of finding an issue, troubleshooting it, and then creating and getting rid of technical debt afterward. In this specific instance, it's more worth it to get it tackled ahead of time to reduce the risk of downtime.
👆🏽 This advice is not unique to DNN, but rather, is true of any framework/solution you may be using.
When upgrading and installing/uninstalling extensions, I almost always take the extra step to see what's happening in the following places:
In this case, we're tackling the technical debt. In general, I often start with comparing two things when I'm in this situation.
As it sounds like you've done, using a compare tool like WinMerge (or any other similar tool) can help you quickly look for and troubleshoot potential issues by comparing the differences. To make it easier, I even take the additional step to re-order anything in the config to match a clean installation of the same version of DNN.
The one thing I wouldn't ever recommend is just leaving something like these in place and not knowing when/if you can remove it. A potential worst-case scenario is that someone with DNN knowledge can hack your site to include a file that seems to be legit, only to keep access to your site. This has happened on several occasions, historically. DNN is still a big target.
Thank you for your exhaustive reply!
I followed the instruction about FiftyOneClientCapabilityProvider. The uninstalling module worked fine, I just needed to manually change some lines in web (dot) config file (such as clientcapability defaultProvider).
How do you explain the issue about Newtonsoft.json.dll file not updated? I noticed that also another production instance (also in this case DNN 9.13.04) has another version of that file. So, what I have seen is that:
- New, clean installation of DNN 9.13.04 has Newtonsoft.json.dll v13.0.3.27908
- Production instance 1 (DNN 9.13.04) has Newtonsoft.json.dll v13.0.1.25517 (the first installation of DNN occurred on 2018, then I updated)
- Production instance 2 (DNN 9.13.04) has Newtonsoft.json.dll v13.0.2.27524 (the first installation of DNN occurred on 2023 then I updated)
Thanks for your attention
Posted By Will Strohl on 10/15/2024 9:54 AM Posted By fabl on 10/15/2024 3:51 AM Hello, Today I compared a fresh new DNN 9.13.04 install with my current production installation (that has been updated during years). I discovered that I had an old Newtonsoft.json.dll (that I copied in production installaiton). I have also seen that there are some dll, in production environment, that there are not in fresh new install of 9.13.04. They are: Dnn.Modules.ModuleCreator.dll DotNetNuke.Website.dll.config DotNetNuke.Providers.FiftyOneClientCapabilityProvider.dll FiftyOne.Foundation.dll Are these old dll that can I safely delete? Thanks! Hello! This thread is a great reminder of why I've developed the upgrade process we use over time. It's very important on every upgrade to keep things as tidy as possible, for all of the reasons: ease of ongoing maintenance, limiting experiencing new bugs, easier troubleshooting in the future, security, etc. In short, you should keep your website as clean and clear as possible of anything it doesn't need. Otherwise, you're going to remain in a never-ending loop of finding an issue, troubleshooting it, and then creating and getting rid of technical debt afterward. In this specific instance, it's more worth it to get it tackled ahead of time to reduce the risk of downtime. 👆🏽 This advice is not unique to DNN, but rather, is true of any framework/solution you may be using. When upgrading and installing/uninstalling extensions, I almost always take the extra step to see what's happening in the following places: Database (tables, views, and stored procedures) Folders: Bin DesktopModules web(dot)config In this case, we're tackling the technical debt. In general, I often start with comparing two things when I'm in this situation. File system (focusing a lot on the Bin folder) web(dot)config file As it sounds like you've done, using a compare tool like WinMerge (or any other similar tool) can help you quickly look for and troubleshoot potential issues by comparing the differences. To make it easier, I even take the additional step to re-order anything in the config to match a clean installation of the same version of DNN. Dnn.Modules.ModuleCreator.dll - This should be safely deleted after uninstalling the module creator module. If the module is uninstalled and this file remains, then just delete it. DotNetNuke.Website.dll.config - Inspect this file and compare anything in it to what you see in the web(dot)config in the root of the site. If you don't absolutely need the overrides in the BOn's config, delete it. These files can and have been sneaky bug-starters for me in the past. DotNetNuke.Providers.FiftyOneClientCapabilityProvider.dll - I'd recommend following Mariette's earlier advice. FiftyOne.Foundation.dll - I'd recommend following Mariette's earlier advice. The one thing I wouldn't ever recommend is just leaving something like these in place and not knowing when/if you can remove it. A potential worst-case scenario is that someone with DNN knowledge can hack your site to include a file that seems to be legit, only to keep access to your site. This has happened on several occasions, historically. DNN is still a big target.
Excellent reply Will! Thank you so much for all the details. I'm not doing the question but I took note from your reply. You might want to consider creating a post in the blog about migration and how you tackle down this beast! I love it! Everybody should read this! Thanks.
Posted By Marco Alvarado on 10/15/2024 1:49 PM Excellent reply Will! Thank you so much for all the details. I'm not doing the question but I took note from your reply. You might want to consider creating a post in the blog about migration and how you tackle down this beast! I love it! Everybody should read this! Thanks.
Hey Marco:
Technically, it's all in the two links below. 😎
These Forums are dedicated to the discussion of DNN Platform.
For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:
Awesome! Simply post in the forums using the link below and we'll get you started.