Latest Contributions by RichZwaap

Hi Nathan, On Mac, you will need to reference the NuGet package directly.  See this help topic for more info.  That documentation is for Visual Studio on Windows, but the steps on Mac are analgous.  You can see Xamarin's documentation here for Mac-specific instructions.  That document is technically for Xamarin Studio, but the UI is not substantially different in Visual Studio for Mac. ... View more

With 100.0 as well as more recent.  So whatever it is, it's not a simple matter of across-the-board OS version incompatibility. Could you try deploying a new app created from our project template to see whether that runs into the same issue? ... View more

That other post looks similar on the surface, but the call stack is quite different.  That looks like a rendering issue, whereas this appears to be due to something making a call to MapView.AddView.  Aside from the stack trace making a call there, the resulting exception message, "AddView is for internal use only," is exactly as we'd expect.  It could be that the OS is invoking this for some reason, but that certainly seems odd.  We have exercised 7.0 and 7.1 devices internally, so that suggests this might be something device-specific.   I just upgraded some of the Android components on my PC, specifically installing the 7.0 and 7.1.1 SDK platforms and the latest Android SDK Tools and platforms tools So deploying and running your app to this device worked previously?  With the app built in Release?  If so, did you also change the target version of your app? ... View more

It looks like MapView.AddView is being called, which is explicitly disallowed.  Is the source code in your app making this call?  Or is it somehow being invoked otherwise?  The call stack suggests that some component named "com.testfairy" might be the culprit. ... View more

This crash was introduced due to changes in Xamarin's Cycle 9 release.  We have reported it to Xamarin, and they have isolated it and made changes targeted at fixing it (see the Xamarin bug here).  Hopefully, they will release an update with the fix soon. In the meantime, you can work around this by downgrading your Xamarin installation to the most recent Cycle 8 release.  You can find guidance on downgrading here.  ... View more

This is a known issue for which we've made a hotfix available.  From this thread: A hotfix for this issue is now available.  To get access to the fix, send an email request to qfe1000sdknetx349667@esri.com.   Please include your name, phone number, and organization/company name. You can also contact Esri Technical Support directly and request delivery of hotfix QFE-1000-SDKNETX-349667: http://support.esri.com/contact-tech-support. Sorry for any inconvenience. ... View more

It will require a bit more looking into to confirm, but I'm inclined to think that this is not a bug.  Rather, the stream returned is just what gets passed back on iOS by the underlying HTTP calls employed by the API.  The fact that it changed from beta to final is likely because of the switch from the managed (Mono) to native (iOS) networking stack.  Nonetheless, initial indications are that this is simply a by-product of how the platform works, much as length is likewise unavailable on the stream returned by the GetDataAsync call on UWP.  The fact that length is not available is not a bug there, either, but rather platform-specific behavior. -Rich ... View more

I gave this a try and am able to repro what you're seeing.  The PortalItem.GetDataAsync method appears to be returning a ProgressStreamContent.ProgressStream on iOS.  That's an internal type, so I don't know precisely how it works, but it appears to download the file contents asynchronously after it's been initialized.  So it appears that the method is returning at the time the download has begun, rather than when it's ended.  I've found that one way around this is to copy the stream that's returned.  So I have something like so:     DownloadStatus = "Downloading item data...";     // On iOS, we get a ProgressStream and on UWP, we get a ReadOnlyStream.  Neither of     // these internal types initialize their Length properties.     var partialItemData = await portalItem.GetDataAsync();     var fullItemData = new MemoryStream();     partialItemData.CopyTo(fullItemData); // Copying causes the entire contents to be downloaded/read     DownloadStatus = $"Download complete.  Data length: {fullItemData.Length}";‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Here, the copy operation apparently waits for the download to complete.  Note that the same approach can also be used on UWP, which likewise doesn't make its Length available on the stream that's initially returned. Hope this helps. -Rich ... View more

Hi Andy, I wonder if this has to do with iOS's enforcement of App Transport Security (ATS).  Beginning with iOS 9, apps have ATS enabled by default, which means that any non-SSL HTTP connections will fail.  Practically speaking, this means that a developer either needs to replace any http://* endpoints with https://*, or declare exceptions in the app project's Info.plist file (see Apple's reference doc here).  Beta users would not have encountered this limitation because the Xamarin iOS Runtime was using the Mono networking stack under the covers, which does not enforce this restriction.  For final, the implementation has been modified to use iOS's native networking stack, which of course does enforce this.  The easiest way to test whether this is an issue would be to either swap out http endpoints with https, or, if that's not easily done, add this to the Info.plist file: <key>NSAppTransportSecurity</key> <dict>   <key>NSAllowsArbitraryLoads</key>   <true/> </dict> That will essentially disable ATS in the app, allowing access to any http endpoint.  While that can be useful during development, it's generally not something that ought to be done in a production app.  Instead, exceptions for individual http endpoints should be declared where an https equivalent is not available. Hope this helps. -Rich ... View more

Any suggestions? On the Build tab of the project properties, make sure that the Platform target reflects what you'd expect.  I just gave this a quick test with the various values (x64, x86, and Any CPU with and without Prefer 32-bit checked), and the client32/64 folders are being copied to output as expected. ... View more

As you found, the VC++ Redistributable is indeed a pre-requisite for WPF Runtime apps.  This is documented under the "Requirements for deployment targets" section of the System requirements topic. The client64 folder ought to be getting copied to the output folder if the app project is targeting x64.  That would be unexpected if that's not the case. -Rich ... View more

Hi Christopher, The behavior you describe is essentially as expected.  When building an app project, there are build events that will copy the Runtime deployment directory into the project's output directory.  But when it comes to deploying an application, it's up to the developer to either see to it that the deployment directory is deployed along-side the executable, or, if it is preferable to deploy it to another location, then the InstallPath property must be set. Hope this helps. -Rich ... View more