I have a working WPF application and deployment that is currently on .net framework 4.8 / ArcGIS Runtime 100.15. I'm upgrading it to .net 6 and ArcGIS Runtime 200, but am having issues with the deployment of the application.
Specifically, there appear to be changes to how the MSIX package is being built and the deployment is no longer able to load the ArcGIS runtime. It now fails with the following error:
'Could not load ArcGIS Runtime (RuntimeCoreNet200_0.dll) or one of its dependencies. Ensure "Microsoft Visual C++ 2015-2022 Redistributable" is installed.'
I have attached a test project that demonstrates the issue, but here are a summary of issues:
Our preference would be to use central deployment for the VC++ redist dependency, but could do local deployment if necessary. At any rate, we have the following questions:
Thanks!
Cameron
Solved! Go to Solution.
Yes .NET 6 does native libraries a little different, since it now has first class support for native runtime libraries.
If you want an installer that'll install on both x86 and x64, you can use the app bundles in the MSIX publishing:
Were you also using an MSIX installer in your .NET Framework app?
> The attached project uses the win-x86 and win-x64 architecture specific runtime identifiers,
v200 requires the runtime identifiers to be win10-x86, win10-x64 and/or win10-arm64.
> After migrating to .net6/ArcGISRuntime200, the client64 and client32 directories are no longer being created.
.NET 6 does this differently. If you build an any-cpu app, they'll be in the \runtimes\[runtime-identifier] folder, but once you go to publishing where you'll be using a specific runtime identifier, these goes in the application root (and the architectures that doesn't apply will be skipped).
I'm not sure which UWP VSIX you're trying to take a dependency on. This isn't a UWP app. As long as you have the vclibs installed on your system, you should be good to go. The requirement is the same as it was with your WPF .NET Framework app.
Note that the error you're getting about VCLibs is just one potential problem. The error is stating it couldn't load the native ArcGIS Runtime assemblies. One reason for that could be that you don't have the right vclibs installed on the system, but in this case the more likely reason is the runtimecorenet.dll and RuntimeCoreNet200_0.dll are completely missing, due to the wrong runtime identifier being used (v200.1 will have a proper build error warning you about that).
Thanks for the quick reply @dotMorten_esri
> v200 requires the runtime identifiers to be win10-x86, win10-x64 and/or win10-arm64.
Are these the only runtime identifiers that can be assigned for a WPF project? When I remove the win-x86 and win-x64 runtime identifiers, I encounter the following build errors when trying to build the MSIX package:
Esri.Runtime200.Msix.WpfClient\obj\project.assets.json' doesn't have a target for 'net6.0-windows10.0.19041.0/win-x64'. Ensure that restore has run and that you have included 'net6.0-windows10.0.19041.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.
I have run nuget restore, but can only get the build error to go away by adding the win-x64 runtime identifier.
> .NET 6 does this differently. If you build an any-cpu app, they'll be in the \runtimes\[runtime-identifier] folder, but once you go to publishing where you'll be using a specific runtime identifier, these goes in the application root (and the architectures that doesn't apply will be skipped).
I do see the runtimes folder in the build output directory, but it is not included when MSIX packages everything up.
> I'm not sure which UWP VSIX you're trying to take a dependency on. This isn't a UWP app.
In terms of referencing the VCLibs, we're adding them as a package dependency as is outlined here:
Please let us know if there is a different way that we should be pulling in the VCLibs dependency using MSIX. Our preference is to have MSIX pull down and install the appropriate VCLibs dependency when the installer runs rather than taking the local deployment approach where we copy the VC++ redist dlls into the output directory.
@dotMorten_esri , I'm not seeing the Any CPU behavior you described here:
> If you build an any-cpu app, they'll be in the \runtimes\[runtime-identifier] folder, but once you go to publishing where you'll be using a specific runtime identifier, these goes in the application root (and the architectures that doesn't apply will be skipped).
I published the ESRI WPF sample project (https://github.com/Esri/arcgis-maps-sdk-dotnet-samples) as Any CPU (after adding a publish profile for Any CPU). Those folders are not included and I'm not able to launch the app after install (same failure message as above). Attached are screenshots of the package contents.
Does the ArcGIS Runtime 200 support publishing as Any CPU? If so, what are the required publish profile properties in order to achieve the Any CPU behavior that you described?
> after adding a publish profile for Any CPU
I'm not quite following this step. When you create a publishing profile you're supposed to pick win10-x86, win10-x64 or win10-arm64. When I said "Any CPU" I mean the normal build/run that doesn't go through the publishing step.
Prior to upgrading to .net6, our build pipeline built the app as any cpu. We have a publishing project that runs via a subsequent build step using msbuild command line parameters. The net result of that step was a single MSIX file that had both the client32 and client64 runtime subdirectories included.
After upgrading to .net6 / runtime 200, I can no longer package our app as we did previously. Based on your comments, it appears that's expected, but has impacts for how we deploy our apps.
Yes .NET 6 does native libraries a little different, since it now has first class support for native runtime libraries.
If you want an installer that'll install on both x86 and x64, you can use the app bundles in the MSIX publishing:
Were you also using an MSIX installer in your .NET Framework app?
Yes, we were using MSIX in our .net framework app as well. Thanks for the info on the app bundles. It seems like that's what we're looking for. I appreciate the help.