Upgrading WPF / CSLA App from .NET 4.7.2 to 6.0. #3351
-
|
Hello, We are just starting to contemplate the idea of upgrading our WPF app (using CSLA 4.2.2) from .NET 4.7.2 to 6.0. This is a pretty big app, so we are not looking forward to doing this because I have a feeling is going to be a major pain in the backend. In order to keep things manageable, as our first step, we would like to leave things as they are (no code changes) and simply move from .NET 4.7.2 to 6.0. After that is done, we will start considering upgrading to the latest version of CSLA. That said, we are looking for some guidance, in particular guidance relating to running CSLA 4.2.2 under .NET 6.0. Is this possible to do with no or minimum code changes? By the way, this will be the first and last (I hope) WPF project that we migrate, so we are completely new to this process. Thank you. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
I honestly don't know. It is likely that anything targeting netstandard 2.0 (ns20) will work fine on .NET 6, Looking at the 4.7.200 release notes (apparently this was before I switched to semantic versioning), it supports ns20, though maybe through a different nuget package? It also says it targets ".NET Core", which probably is some older version that is no longer supported. My guess is that when you reference the package from a .NET 6 app that nuget will select the ns20 target - but maybe not? In any case, it does look like it will probably work. Keep in mind that you will be switching from the netfx (.NET Framework) codebase to what has become the mainstream codebase today - but in an earlier form. So things like COM+ and some other netfx-only features will become unavailable in CSLA (as well as your WPF app). |
Beta Was this translation helpful? Give feedback.
-
|
It is also the case that you may be able to move to CSLA 4.11.2 - the last of the v4 releases - without much difficulty. That would give you a whole bunch of bug fixes that often were discovered in the .NET Core codebase. Moving to CSLA 5 might not be too bad, and would get you close to current. Moving to CSLA 6 is where dependency injection became mandatory, and that does require some code changes throughout most apps. |
Beta Was this translation helpful? Give feedback.
It is also the case that you may be able to move to CSLA 4.11.2 - the last of the v4 releases - without much difficulty. That would give you a whole bunch of bug fixes that often were discovered in the .NET Core codebase.
Moving to CSLA 5 might not be too bad, and would get you close to current. Moving to CSLA 6 is where dependency injection became mandatory, and that does require some code changes throughout most apps.