Using the Esri Runtime in a Class Library

1904
14
12-04-2019 07:54 AM
MichaelHamsa
Occasional Contributor

Hello,

We have developed some .NET 4.7.2 Class Libraries and are using the Esri Runtime SDK in those class libraries. These class libraries get compiled into DLLs and those DLLs are used in other client applications. When the code in these class libraries attempts to open a mobile map package (MobileMapPackage.OpenAsync), it seems like something is happening in the Runtime, like an unhandled exception of some sort, and the mobile map packages do not load. We've wrapped the call in a try/catch but no exceptions are thrown. If I try to add another call before MobileMapPackage.OpenAsync, like MobileMapPackage.IsDirectReadSupportedAsync, we do get an exception - Unable to load runtimecore.dll - even though all of the ArcGISRuntime folders, assemblies and dependencies are in the correct location under the bin folder.

I'm really at a loss right now. I've tried the things I know and I'm not having any luck.

I've attached a simple Visual Studio 2019 solution that you can use to reproduce the problem. You may need to "Restore NuGet Packages", once you open the solution. Also, The file name for the mobile map package is hard-coded, so you will need to change that code before you run the app Otherwise, it should be all ready to go. You can step through the code and notice that once you get the MobileMapPackage OpenAsync or IsDirectReadSupportedAsync you will start running into problems.

Thanks,

Mike Hamsa

0 Kudos
14 Replies
dotMorten_esri
Esri Notable Contributor

>  I really think it you ran the app I attached and stepped though the code you’d get a better idea about what’s going on.

I did and identified why the load operation wasn't working (assemblies not loaded). Now that we addressed that, I can't step further because I fail (correctly) on missing the MMPK, but since that was expected behavior when I don't have that file, I can only assume something else is going on with the file itself.

Make sure you enable mixed debugging (both native and managed), and monitor the output window for any hints as well.

0 Kudos
MichaelHamsa
Occasional Contributor

Morten,

Thanks for the response. You can basically use any mmpk; just change the path and file name in that code. I really just kind of quickly put that app together so we could use it to reproduce this problem.

I’ve got most of the debugging options enabled right now, and I’ve set Visual Studio to stop at just about any kind of first chance exception that’s thrown (including javascript exceptions). I’ve not sure there are many other debugger options I can use on my end.

Mike Hamsa

Chief Technology Officer - GeoSpatial Innovations, Inc.

P: 512-982-6735

0 Kudos
MichaelHamsa
Occasional Contributor

Morten,

Just looking through your last response again, and I wanted to add that the mmpk seems to be OK - we can open it using MobileMapPackage.OpenAsync in other places. There just seems to be something interesting occurring when we attempt to open an mmpk through a class library. Again, you can really just plug in the name of any mmpk you have and I'd expect that you would see the same problem as you step over the call to MobileMapPackage.OpenAsync. If it works for you then I can dig in a little farther on my side.

Just wanted to add those details.

Thanks again,

Mike Hamsa

0 Kudos
dotMorten_esri
Esri Notable Contributor

D'oh! Can't believe I didn't spot this. You're calling async code from C++, and that doesn't go well.

Try chancing the async calls to use .Result instead to make them synchronous:

bool b = MobileMapPackage.IsDirectReadSupportedAsync(m_PackageFileName).Result;

Then you hit the catch code and you can see a proper error message.


HOWEVER don't use .Result (or .Wait()) in production as it can create lots of dead-locks if your app is multi-threaded. You should probably switch do some sort of callback/eventing model instead.

0 Kudos
MichaelHamsa
Occasional Contributor

Morten,

Well, that was certainly the problem. Thank you very much for taking a closer look at it.

Everything is working perfectly now!

Thanks again,

Mike Hamsa

Chief Technology Officer - GeoSpatial Innovations, Inc.

P: 512-982-6735

0 Kudos