UWP release mode issue

[mattheworiordan]

From customer in ticket 1921:

Xamarin UWP is working fine in debug mode but our application fails immediately on start up in release mode.
Error message:
'App.UWP.exe' (Win32): Loaded 'D:\Projects\TexhXpert\App\App\App.UWP\App.UWP\bin\x86\Release\AppX\App.UWP.exe'. Module was built without symbols.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ntdll.dll'. Symbols loaded.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\kernel32.dll'
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Symbols loaded.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcrt.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\combase.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ucrtbase.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\rpcrt4.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sspicli.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cryptbase.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\bcryptprimitives.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sechost.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\oleaut32.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcp_win.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Windows\SysWOW64\bcrypt.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled.
'App.UWP.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Microsoft.NET.Native.Runtime.1.3_1.3.23901.0_x86__8wekyb3d8bbwe\mrt100_app.dll'. Symbols loaded.
The thread 0x1ccc has exited with code -1073741515 (0xc0000135).
The thread 0x2a14 has exited with code -1073741515 (0xc0000135).
The thread 0x18b8 has exited with code -1073741515 (0xc0000135).
The thread 0x1e4c has exited with code -1073741515 (0xc0000135).
The program '[5804] App.UWP.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
Activation of the Windows Store app '65355F4C.App_898fp5ejf0d60!App' failed with error 'The app didn't start'.

I then asked:

It's a bit unclear what DLL is missing from this log, which is a bit annoying.
Have you tried removing Ably to confirm that is indeed Ably that has a missing dependency?

Customer responded:

It is working after un-installating of ably Package.
Ably is using multiple OS native assembly as kernel32, ntdll which is not loading in release mode, find form below error list..
it is working well in debug mode.

[marto83]

@mattheworiordan can you ask the customer if they have a sample project that reproduces the issue.

[mattheworiordan]

@marto83 have asked

[marto83]

Just to confirm. I can reproduce the issue and am trying to find how to get it fixed. I'm open to suggestions if there are any :)

[DaTester]

Hi @marto83 - This issue might be caused by the msgpack.cli dependency.
msgpack/msgpack-cli#206

[marto83]

Thank you @DaTester. I had a look at the bug and it will not be fixed until the next RC. :(

My options are kind of limited. I think for the time being I will fork the msgpack repo and create a new nuget package that fixes this until the official 0.9 rc comes out.

[DaTester]

Ok I understand @marto83, can give me estimated timescale on next RC? so we can plan for testing/release at that time.

[marto83]

@DaTester to update you I'm stacked at the moment and won't have time to look into it for at least the next week.

However, if you want to fork the MsgPack.Cli and release a version that removes the broken dependencies I'll be happy to release a new version pointing at your implementation.

[DaTester]

Thanks for the info @marto83 , It's ok we can wait as our developer is fixing critical issues in our app at present.

[marto83]

Hi @DaTester. I've released a new version with the upgraded MsgPack.Cli dependency. Can you please try again with that version.

[marto83]

Actually. I create a test project and still get the same error :(. It must be another package. Or maybe I need to create a separate nuget config for UWP. I'll look into it.

[DaTester]

Hi @marto83, Sounds like a bit a pain this issue. I'm pretty sure it's MsgPack.Cli that causes the failure because i tried including the package in a new Xamarin UWP project and it fails the same way in release mode. I really do hope you can find a work around for this issue.

[marto83]

I updated to the latest beta of MsgPack and still get the error. Which version did you use?

[DaTester]

I tried it with the the latest stable version 0.8.1 and also tried the 0.9.0 beta 2 - both have same issue.

[marto83]

@DaTester MsgPack is not ready. The only other way would be to find a way to switch off msgpack and release a json only version. Let me chat with @mattheworiordan.

[DaTester]

Hi @marto83 - tried the latest MsgPack release (0.9.1). I'm afraid issue still exists for UWP release version. I was really hoping issue would have been addressed in the latest package :-(

[marto83]

Oh. That's disappointing :(

[DaTester]

Hi @marto83, We built the MsgPack using the latest source from NuGet and found it works fine in UWP release mode ( I have attached the MsgPack dll we built). But when we then include the ably.io package there is a conflict (two MsgPack files). Is it possible for you to create a ably.io package for us using the msgpack.dll? this will hopefully allow us to put our UWP app version on the windows store.
MsgPack.zip

[marto83]

@DaTester. That's great news. We can't publish a package with a local dependency unless you inline the other dll and last time I tried ILMerge didn't like the MsgPack dll. The other option is for you to pull this repo and change the dependency from nuget to your msgpack dll. This way you can build the library against it and you should be able to include ably + msgpack as local dependencies.
To do so, please pull the latest master. If you don't have Xamarin studio installed you can just remove the iOS and Android projects. Reference your msgpack dll and remove the nuget reference and compile it. This should work.

[DaTester]

ok thanks for the information. In our current development environment we use visual studio 2015 update 3. Do we need to update to VS 2017?

[marto83]

@DaTester. Yes we are using 2017, so it's easier if you have it. You can run both 2015 and 2017 alongside each other.

[DaTester]

Thanks @marto83 , This workaround allowed us to to create package for UWP 👍
fyi i raised the issue with the msgpack.cli owner regarding the problem.

[marto83]

@DaTester I'm glad to hear that. 👍

[mrueedi]

Hi all
I had the same problem and the same workaround worked.
Meanwhile MsgPack.Cli 0.9.2 is available in NuGet and local ably finally works with that too. Would it be possible to created an updated ably.io package, that references MsgPack.Cli 0.9.2?

[mattheworiordan]

@mrueedi you seen #145? We are releasing a version with MsgPack disabled completely in fact, until we are 100% confident MsgPack is stable.

[mattheworiordan]

This is no longer an issues as MsgPack is no longer bundled into the library. Once we have a stable release for MsgPack, then we will potentially reintroduce.