Cleaning App_Data\ExtensionPackages folder

[skarpik]

Description of problem

Is your feature request related to a problem? Provide a clear and concise description of the problem.

Description of solution

Provide a clear and concise description of what you want to happen.

Description of alternatives considered

Provide a clear and concise description of any alternative solutions or features you have considered.

Screenshots

If applicable, provide screenshots to help explain your problem and/or feature.

Additional context

Add any other context about the feature that may be helpful with implementation.

Affected version

• [x] 9.3.2
• [x] 9.3.1
• [x] 9.2.2
• [x] 9.2.1
• [x] 9.2
• [x] 9.1.1
• [ ] 9.1
• [ ] 9.0

Affected browser

• [ ] Chrome
• [ ] Firefox
• [ ] Safari
• [ ] Internet Explorer
• [ ] Edge

[skarpik]

To support the import/export site export function, DNN stores extensions in the App_Data\ExtensionPackages folder. As new versions of a module are installed, old versions of the module are not removed from this folder and a significant number of old files can accumulate.

It would be helpful to have a button somewhere (maybe in Server Settings) where one had the option of either erasing all but the most recent versions of modules stored in this folder or all the files (if there was no desired to use the import/export site feature). An alternative would be to modify the module installation procedure so that old versions of modules are automatically deleted from this folder when a updated version is installed. Either of these approaches would be a nice addition to DNN.

[valadas]

@dnnsoftware/tag I think this makes sense right, or do you guys see any other reasons than Import/Export for keeping those extensions installers, specially for versions that are older than the currently running ones ?

[sleupold]

IMO the older version should be deleted as soon as the newer one is installed or transferred via export/import. In addition we might need to perform a one-time cleanup of all older versions during upgrade. Are stored packages deleted, when a module is deleted? Does this affect modules or all type of extensions?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sleupold]

this is stlll a valid improvement

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[sleupold]

This is still an issue. Is there anyone willing to contribute a pull request?

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[sleupold]

still an issue :)

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[EPTamminga]

Still an issue

[Timo-Breumelhof]

So I guess it's safe to manually delete the old install packages?

[sleupold]

@Timo-Breumelhof yes, these packages are provided for Evoq export/import 8and are helpful if you need to re-install a package), but are not necessary for DNN to run.

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[sleupold]

we are still lacking a cleanup mechanism for older package versions

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[stale[bot]]

This issue has been closed automatically due to inactivity (as mentioned 14 days ago). Feel free to re-open the issue if you believe it is still relevant.

[trouble2]

Still an issue...

[moorecreative]

I LOVE that it stores the installers for these as that's a wonderful benefit for the Import/Export system. But I am fully supporting some type of cleanup, or opt-out for the process... but at the least, it would be great if it removed the old ones when a newer version is installed. Maybe it could be a cleanup button as part of a Maintenance or Performance tab under Persona > Settings > Server

[mitchelsellers]

I'm going to re-open this one, I also pinned it to prevent future closure

Given the way that DNN Installers work, My proposal here is that it should ONLY keep the most recent version, as you cannot install an older version of the module anyway, so you cannot roll back.

Deletion of a module should also make sure that this folder is cleaned.

[moorecreative]

That sounds great @mitchelsellers , it would be an element that could be self-maintaining. Then if people want to clean up more, we can have help text in Docs that tells people how it works, what it's used for and let them know it's OK to delete if they don't plan to use the import/export feature.

Actually, that's a good question: If the files are deleted manually, will the import/export function get tripped up by expecting but not finding the module resource files? Or does it gracefully handle them not being present?

[EPTamminga]

DNNReports and DNNEvents do the cleanup during the install of a version. The cleanup is a normal part of the cleanup branch of the install manifest. I think that extensions should be responsible by themselves for the cleanup, or does it have to be a general option in DNNPlatform?

[mitchelsellers]

Modules should NOT be touching that folder.

That function is an automatic part of the installer. At a DNN global level. Not a module function.

[EPTamminga]

That might be True, but imo an extension is resposible for its own artifacts, including clean up of old and potentialy vulnerable parts.

[mitchelsellers]

Yes. But these artifacts are not it’s artifacts. They are the platforms artifacts to support import/export.

Manipulation of these files by individual extensions could have unintended behaviors depending on usage. In this case. Most likely ok given DNN really only needs the one version.

But not a best practice behavior IMHO anyway. As it’s manipulation of a core feature by a module.

We should fix the core feature. Not bandaid a fix module by module.

[EPTamminga]

I understand the answer, but until things work correctly, bandaid is useful, when the core is wrong. We have upgraded a serious # of sites in various DNN steps. The end result was always that 80% or more of the size of the site was defined by useless copies of old install packages, including copies of the various incremental releases of the platform itself. Add that to the fact that we never ever use module export on any site it is a total waste. Me thinks that the implementation was done in Corp's time, when more things were done half.

[WillStrohl]

FYI - as a workaround, until something more thorough is added to the DNN core, we have written a DNN prompt to take care of this problem.

https://github.com/UpendoVentures/Upendo-Dnn-Prompt/wiki/delete-packages

We mostly use this kind of command before and after an upgrade on websites where we have no intention of using the import/export features. (Where we also disable that scheduled task.)

[patrickryan79]

So it's perfectly fine to delete older versions of each assembly?

[valadas]

The way I understand it, you only need the currently installed versions and only if you use Export.