Use older DLL's versions in more recent nop versions?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
3 years ago
I'm sure the answer is no, simply because the data layer or data structures are different.

But I'll just like some opinion on this? I would be nice to upgrade to newer nopcommerce versions if the DLL's of plugins are somehow backward compatible.
3 years ago
(Actually, it sounds like you want old DLL to be "forward" compatible ;)
No, in general it's not possible.  A long time ago when the core was not being changed so drastically, one could sometimes just alter the "SupportVersions" in the Description.txt (now call plugin.json).  But with recent changes for .NET Core, removal of EF, etc. and the frequent updates for dependent libraries (like Autofac, etc), it's not going to work.  You have to wait for the plugin to be upgraded, or if it's custom, then make adjustments and recompile it.
3 years ago
Of course it is possible but it may not be feasible anymore due to the state nopcommerce was designed. Its a whole application, built all for 'one' due to library dependencies.

If plugins were 'interfaced', 'decoupled' from the core,  'versioned' , in theory inputs and outputs should be identical regardless of the version. It should just work. Give developers the option of marking their libraries as forward compatible.

I'm sure many nopcommerce stores owners are always in the dilemma of upgrading the core because the system is somewhat coupled. Need to worry about: data layer, dependencies, custom code, licensed libraries, all this before upgrading the core application. Many will just put it in the too hard basket.

Once you introduce multistores like my implementation and possibilities of multiple license libraries,  every small upgrade even minor takes effort. I'm technical, imagine store owners that aren't.
3 years ago
Given the architecture is heavily dependent on DI (dependency injection), I don't think its even "possible". (The Autofac version must match).  And even if that was not the case, it would be more than just "marking their libraries as forward compatible"; you'd also have to include all your version dependent dlls in your plugin folder)
3 years ago
New York wrote:
Given the architecture is heavily dependent on DI (dependency injection), I don't think its even "possible". (The Autofac version must match).  And even if that was not the case, it would be more than just "marking their libraries as forward compatible"; you'd also have to include all your version dependent dlls in your plugin folder)


Yes I understand. That is the problem. There shouldn't be any DI for plugins. Its a plugin, stand alone, that is should communicate through an interface. Currently, the architecture is not really  a plugin design, its more like a load on demand library (with dependencies).

Having plugins truely stand alone will also open up the market place for developers to reach a broader audience.

Think about this, woocommerce core has a degree of backward compatibility. And who is more important? Your customer base or the current architecture?
3 years ago
jayc wrote:
...Having plugins truely stand alone will also open up the market place for developers to reach a broader audience.

For other ASP.NET based shopping carts?

jayc wrote:
Think about this, woocommerce core has a degree of backward compatibility. And who is more important? Your customer base or the current architecture?

WooCommerce uses the PHP scripting language.  It's very different compared to ASP.NET.    Can WooCommerce plugins be used in Magento?
3 years ago
New York wrote:
For other ASP.NET based shopping carts?


No. Just for nop. Having plugins compatible on multiple shopping carts would require an open standard.

New York wrote:
WooCommerce uses the PHP scripting language.  It's very different compared to ASP.NET.    Can WooCommerce plugins be used in Magento?


Do you think nop is restricted based on the technology of choice or by its design decision? As mentioned, at the end of the day the customer base may not be technical. They might not even care so much about the technology behind the scenes. They just want a robust shopping cart that is easy to upgrade. Its mainly the developers/software house choice of the technology they wish to implement.

I'm just expressing my opinion, experience and frustration on continuously upgrading nop since 3.0. My previous background is a solutions architecture and I think the upgrade path takes effort.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.