Upgrading to 4.1 with support for legacy 1.x

[rmelancon]

Currently we have a site that uses versions 1.x and 2.x. There were too many breaking changes between versions 1 and 2 for us to convert all of our pages, so we recompiled one of the versions with a new namespace so that 1 and 2 could live in the same website.

Now we are looking into version 4.1 and wondered if we could do the same thing by recompiling and namespacing version 4 (or 1). If the upgrade from version 2 to 4 has no breaking changes then we could do away with version 2 but we still need to support version 1 on the same site as version 4.

Is this a possibility? It appears the source is not available like it was in the past.

Thanks for you time,
Robb

[fabricio.murta]

Hello @rmelancon!

Source code for 3.x and 4.x are available for premium subscriber users only. And well, I'm sorry to turn down your hopes but every major version upgrades are inherently marked by breaking changes in the code. So if you got enough from v1 to v2 to split the projects apart, imagine from v2 to v4, which is two versions different.

But if you consider the webforms pages' syntax for components, comparing source samples from version 1 to version 3, the feeling is that the overall structure of pages is much more similar from v2 to v4 than it was from v1 to v2. Even less between v3 to v4. This indicates that as the code matures, structural changes tend to be smaller over time. But it will be too much to say they are fully backwards compatible, nevertheless.

Hope this helps!

[rmelancon]

Thanks for the information. I understand that major upgrades will occasionally have breaking changes and in our case there was too much legacy code to upgrade. In order to use the newer versions for "new" code, we recompiled v1 to a new namespace and built new screens in v2.x

Going forward, we plan to subscribe to "premium", I just want to make sure I can still support screens built in v1 running side by side with v4. I have installed 4.1 and upgraded all the v2 screens to v4 as the breaking changes were not lengthy. The v1 screens are still v1 and are referencing the different namespace. I am running into a problem with ext.net.utilites, it seems v1 and v2 used the same version of this dll but v4 is on a newer (2.5) version? but I am assuming this can be figured out. I just want to make sure that it is possible before moving forward with upgrading to v4 premium.

Thanks,
Robb

[geoffrey.mcgill]

Hi Robb,

If you were able to get v1 and v2 running side-by-side, then getting v1 + v4 running together should be possible. I'm not entirely sure how you did it, but the fundamental architecture has not changed between those releases.

Unfortunately the v1 to v2 upgrade did introduce many breaking changes. The upgrade process from v2 to v4 should be relatively smooth. There will likely still be a few breaking changes, but they should be minor.

[rmelancon]

So it seems v1.x and v2.x used the same version of the Ext.net.Utilities (2.4.0.0) but v4.x uses a new version?

[fabricio.murta]

Hello Robb!

Yes, the version of Ext.NET Utilities has been upgraded in between v2 to v4. So this can be both a problem and a solution.

Actually, I'd suggest best way to keep both versions would to keep v1 under a virtual application in the same website to keep things really separated (virtual path, different application pool and DLLs and root, but same website). With this approach, no namespaces nor DLL changing would be necessary at all!

But if you are going to merge v1 and v4 in the same website you would need to rebuild ext.net utilities as well and change their namespace. I don't think other libraries that Ext.NET links to are linked to Ext.NET.Utilities, but in potential, other DLLs required to run both versions of Ext.NET could conflict with it too.

And, before I forget, here's the source for Ext.NET Utilities. If you fancy git, you can walk back in time and build the version before it introduced the breaking change with Ext.NET v1 and rename its namespace, doing the respective change in v1 sources.
- Github repository for Ext.NET Utilities.

Hope this helps!

[rmelancon]

Thanks. I think it will be too confusing to move different forms into different websites/projects as logically they are all the same "application" and the screens interact in varying degrees. If it was a handful of screens that might work but that is not the case. I am going to go the route of namespacing the utilities dll and hoping there aren't too many other conflicts. I have put in a request to purchase a license so that should be coming soon. I anticipate needing a bit more help to get this right.

Thanks,
Robb

[rmelancon]

Am I going to have a problem with the Newtonsoft.Json.dll?

[rmelancon]

Version in the link for github 2.5, how do I get to 2.4, the only branch i See is 1.3... so is 1.3 the utilities I need for v1? and 2.5 is for version 4?

[fabricio.murta]

Hello! I believe you may have, yes, issues with Newtonsoft Json. Running two different versions of Ext.NET on the very same environment is not really supported, many conflicts can potentially happen and we can't foresee them. It is not something we ever tested, but I believe some recent changes to Json made some errors and had to be readapted, but nothing too hard to tackle with and you would be able to use new Json with old Ext.NET 1 without much effort.

About Ext.Net.Utilities, the version in github is the version available from NuGet too. I believe at least some three last versions have their full change history in github and can be easily moved back and forth (git knowledge required). Although the readme says '2.4.0', you can see last commmit messages stating the assembly being moved to 2.5.0.

Hope this helps!