Upgrading WPF Application

[JoeHershman]

I have a need to upgrade a large legacy app built with the Runtime for WPF that is running on 100.6 on Windows 10 laptops. 

We have a short timeline for an initial release.  However, we will require an ability to work with data that is in the Utility Network at the latest versions (UN v6 with ArcGIS Enterprise 11.1), which is a new requirements.  Also this app will be running on Windows 11 laptops

My immediate term plan was to upgrade to the latest 200.x version of the API but to keep with WPF.  I was wondering if there is anything I should be concerned about or aware of with this migration in advance.  Would possibly going to 100.15 still support the UN and be easier? 

Is there any reason this does not seem like the best away to get deployed in the short term, we do have plans next year to look at a longer term objective of moving it to a MAUI to be multi-platform, but right now speed is of utmost concern

Thanks in advance - Joe

@MichaelBranscomb 

@dotMorten_esri 

[Mike_Quetel]

WPF and .NET 6 work great... once you get there.  I had a rocky experience using Microsoft's .NET Upgrade Assistant tools.  While the migration tools completed and I mitigated any errors and serious looking warnings, I ended up with a project that would build in debug and release modes, but then fail at runtime in the Esri.ArcGISRuntime.ArcGISRuntimeEnvironment.Initialize() method call.  Error was:

System.InvalidOperationException: 'Could not load ArcGIS Runtime (RuntimeCoreNet200_0.dll) or one of its dependencies. Ensure "Microsoft Visual C++ 2015-2022 Redistributable" is installed.

It was installed. Worked the problem with esri for a while, verified I had a working toolchain and could build sample apps, but my solution was just not working.  Ended up creating a new solution with esri's template then moving the code files manually from the busted solution in and got it working.  Tedious but it happens.

As I mentioned, once completed I've got a solid and working build, but it wasn't a straightforward path to get there.  I've had no problems since then, upgrading to 200.1 and 200.2 since.  100.15 to 200.0 was the painful part.  I'm relieved that migration is behind me and 200.2 app is in production with hundreds of users, no reliability or performance problems.  The 200.1 and 200.2 runtimes are solid.  

I talked about the efficacy of WPF with one of the .NET runtime engineers at the last Dev Summit.  Their opinion was, it's not going away anytime soon and while it might not be the shiny thing in the toolbox, it's widely used, stable and gets the job done. 

Lastly, you didn't ask for this opinion, but here it is anyway...  I wouldn't be looking at MAUI in 2023/2024 with any seriousness unless you absolutely must have a multi-device, cross platform solution.  If that's true, don't underestimate how large an effort it will be to take an existing WPF desktop app and build mobile and desktop apps from it.  Tons of UI work ahead, likely tons of refactoring as well. 

I've dipped into various developer forums to keep tabs on how things are going with MAUI from developers actually using it and it's scared me away.  Immature tooling, bugs, regressions, lots of baggage as in the Xamarin days.  No thanks.  At least not anytime soon.

[JoeHershman]

@Mike_Quetel thanks for the input.  Perhaps I will look at that approach to start, I have seen similar types of things migrating other frameworks.

In terms of MAUI, it would not be specific to this application, we also have legacy Xamarin apps so there is a goal in consolidating to a single platform.  But MAUI is not worth serious discussion until at least Core 8 is released.

[dotMorten_esri]

I agree that .NET MAUI had some quality issues, but a lot of that has been addressed in v8. The release candidate is already out with a go-live license, so you could get started on it. They made huge improvements in quality.

Just to be clear: You don't have to move from .NET Framework to .NET 6 when going to v200. Personally I don't like the upgrade assistant very much. I had more luck just creating a new .NET 6 WPF project and copying that new .csproj over the old one (or moving old files over to the new project.

[dotMorten_esri]

You should be fine moving to 200. I'd recommend you briefly upgrade to 100.15, and recompile. Look for any obsolete API warnings and address those. Any APIs that are reported obsolete have been removed in v200, but most obsolete warnings should tell you what to use instead (if you move directly to 200 you will just get build errors for those APIs, instead of helpful warnings). Other than that, you should be able to just change the target to v200.

Do note that .NET Framework 4.7.2 is now required, or if you're using .NET, .NET 6 is required (It'll be .NET 8 by the time 200.3 rolls around).

A lot of work has been done to UN in the last few releases, so I'd encourage you to go to the 200.x releases.

Moving to MAUI is definitely more of a process - but that's mostly around your UI and dealing with mobile requirements - the business logic for the Esri APIs are mostly if not completely identical.

[JoeHershman]

@dotMorten_esri    So to confirm what you are saying, I could just stick with Framework 4.7.2 and  not move to Net Core for the 200.x release

[dotMorten_esri]

>  I could just stick with Framework 4.7.2 and  not move to Net Core for the 200.x release

Yes. .NET 6 is optional. .NET Framework is still very much supported, and probably will be for a while.
Now there are benefits to moving (performance being one), but again not at all a requirement.

[TonyWakim]

@JoeHershman upgrading from 100.x to 200.x should allow you to keep using the full UN capabilities in addition to new ones provided in the 200.x release.

Please refer to the Migrate from 100.x to 200.x documentation, as well as to the Release notes for 200.0, 200.1 and 200.2 for improvements in the Utility Network capabilities in the Native Maps SDKs.

For more specific UN advancements in recent releases please refer to:

Offline utility networks in ArcGIS Maps SDKs for Native Apps
Offline Utility Networks in ArcGIS Maps SDKs for Native Apps: Part 2
Offline Utility Networks in ArcGIS Maps SDKs for Native Apps: Part 3

One thing to note: Any deprecated API in the 100.15 release have been removed in the 200.x release.

You should have been recieving warnings for any deprecated API in the 100.15 release.

For example: UtilityTier.traceConfiguration and UtilityNamedTraceConfiguration.traceConfiguration are now a method GetDefaultTraceConfiguration() on their respective classes.