Local Locators not working in 100.7?

2281
11
Jump to solution
12-23-2019 01:35 PM
KyleGruber
Occasional Contributor II

Since upgrading to 100.7, any action I try with LocatorTask inside a MobileMapPackage seems to be bombing with an obscure exception.

System.Windows.Threading.Dispatcher => Esri.ArcGISRuntime.ArcGISRuntimeException: Invalid response

   at Esri.ArcGISRuntime.ArcGISException.HandleCoreError(CoreError error, Boolean throwException)

   at RuntimeCoreNet.GeneratedWrappers.Interop.CheckError(IntPtr errorHandle, Boolean throwOnFailure, GCHandle wrapperHandle)

   at RuntimeCoreNet.GeneratedWrappers.CoreTask.Get()

   at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler`1.OnCompleted(Object sender, EventArgs e)

--- End of stack trace from previous location where exception was thrown ---

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler`1.<CreateInternal>d__7.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

   at [REDACTEDMETHOD] in [REDACTED].cs:line 755

   at [REDACTEDMETHOD] in [REDACTED].cs:line 525

--- End of stack trace from previous location where exception was thrown ---

   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)

   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)

   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Literally, just calling LocatorTask.LoadAsync is causing this exception.  Is there something I maybe missed in the release notes?  This is with a v2.4 Locator with a Street Address role created in ArcGIS Pro 2.4.3 packaged inside an MMPK created with ArcGIS Pro 2.4.3.  Esri.ArcGISRuntime/Esri.ArcGISRuntime.WPF 100.7.  Project targeting .NET Runtime 4.6.2.

I'll create a repro project when I get a chance.

Thanks as always.

1 Solution

Accepted Solutions
BradNiemand
Esri Regular Contributor

Kyle,

Locators created with the Create Locator tool and packaged in a MobileMapPackage are only supported in 64 bit applications.  You can still use the Create Address Locator tool to create locators and package them in a MobileMapPackage to be used in 32 bit applications.

Brad

View solution in original post

0 Kudos
11 Replies
KyleGruber
Occasional Contributor II

I was really hoping this was something screwy going on in my main (complex) project, but the same thing is occurring in a simple repro app.

https://helpdesk.alertts.com/content/Debugging/ArcGISReproApp_12232019.7z 

I also verified that downgrading to 100.6 fixes the problem.

JohnFix1
New Contributor III

We are having the same problem with an app we are working on. Only difference is we built a "locator" (not address locator) in ArcGIS Pro with both house address and street range styles. 

This has become a show stopper in our development efforts.

KyleGruber
Occasional Contributor II

John,

Just to clarify, I'm also using "Create Locator", I've been referring to them as "New Style Locators" since ESRI refuses to give us a definitive way to clearly separate locators (only available in ArcGIS Pro) and address locators.  The only difference is mine only contains a street address role.

Thanks for pointing that out as I realize the language in my original post was ambiguous, I edited to clarify.

0 Kudos
MarkBockenhauer
Esri Regular Contributor

Are you building 32 bit apps?

0 Kudos
KyleGruber
Occasional Contributor II

Mark Bockenhauer,

In my case, yes.  Turning off Prefer 32-bit and recompiling does fix the issue, but obviously is not a fix due to the fact that we need to continue supporting 32-bit OSes, and I would expect ESRI would give us a healthy cushion period if you were planning on deprecating 32-bit support from the SDK.

Edit:  Sorry if this sounded a bit harsh, I'm not suggesting you were suggesting making apps 64-bit as a resolution, I just wanted to make it clear that it definitely would not be a viable resolution for us (and I'd assume many other SDK clients) at this time.

0 Kudos
MarkBockenhauer
Esri Regular Contributor

Kyle,

Thanks for the feedback...    I recently heard that the new locators required 64 bit, so that is why I asked.  I will make sure the teams see this thread.  

Mark

0 Kudos
KyleGruber
Occasional Contributor II

Mark,

Thanks for the info, looking forward to clarification.  I have to admit that it would be very disappointing if this change was made without any sort of notice or warning.  While in an ideal world all applications would be running in 64-bit by now, we all know it's not an ideal world.

Brad Niemand‌ Any input/information you have on this?

0 Kudos
BradNiemand
Esri Regular Contributor

Kyle,

Locators created with the Create Locator tool and packaged in a MobileMapPackage are only supported in 64 bit applications.  You can still use the Create Address Locator tool to create locators and package them in a MobileMapPackage to be used in 32 bit applications.

Brad

0 Kudos
KyleGruber
Occasional Contributor II

Brad,

Thank you for the information.  I have to say this is pretty shocking, and disappointing that there was no information or warning about this.  The new locators were working fine in x86 up to 100.6.  Our mapping application has been completely designed around the new locators, we would not be able to go back to the logic and deficiencies of the address locators.  I'm pretty sure Visual Studio 2019 still defaults "prefer 32-bit" when creating a new WPF app, and I'm fairly certain we have a decent amount of clients running 32-bit versions of Windows out in the field.

0 Kudos