Azure WebApp does not work on 32-bit mode.

[JohnDoeKyrgyz]

I attempted to use the template to create a sample app and deploy it to Azure. The deployment appeared to work correctly, but when I access the site in Azure I get an HTTP 502. The commands I ran were:

mkdir SafeQuickTest dotnet new SAFE dotnet run -- Azure

The HTTP 502 looks like this:

For some reason, it appears that the application cannot start. Evidence of this is in the eventlogs.xml file:
<Events> <Event> <System> <Provider Name=".NET Runtime"/> <EventID>1023</EventID> <Level>1</Level> <Task>0</Task> <Keywords>Keywords</Keywords> <TimeCreated SystemTime="2021-04-28T21:20:47Z"/> <EventRecordID>192917875</EventRecordID> <Channel>Application</Channel> <Computer>webwk000003</Computer> <Security/> </System> <EventData> <Data>Application: w3wp.exe CoreCLR Version: 5.0.421.11614 .NET Version: 5.0.4 Description: The process was terminated due to an internal error in the .NET Runtime at IP 64171044 (640E0000) with exit code 80131506. </Data> </EventData> </Event> <Event> <System> <Provider Name="Production Breakpoints"/> <EventID>4166</EventID> <Level>1</Level> <Task>0</Task> <Keywords>Keywords</Keywords> <TimeCreated SystemTime="2021-04-28T21:20:47Z"/> <EventRecordID>192918062</EventRecordID> <Channel>Application</Channel> <Computer>webwk000003</Computer> <Security/> </System> <EventData> <Data>IfFailRet(pNamedPipe-&gt;Read((BYTE*)&amp;controlRequest, sizeof(SnapshotHolderControlStruct))) failed in function CSnapshotHolder::HandleNewPipeConnection: -2147024787</Data> </EventData> </Event> <Event> <System> <Provider Name=".NET Runtime"/> <EventID>1023</EventID> <Level>1</Level> <Task>0</Task> <Keywords>Keywords</Keywords> <TimeCreated SystemTime="2021-04-28T21:20:55Z"/> <EventRecordID>192925375</EventRecordID> <Channel>Application</Channel> <Computer>webwk000003</Computer> <Security/> </System> <EventData> <Data>Application: w3wp.exe CoreCLR Version: 5.0.421.11614 .NET Version: 5.0.4 Description: The process was terminated due to an internal error in the .NET Runtime at IP 64171044 (640E0000) with exit code 80131506. </Data> </EventData> </Event> <Event> <System> <Provider Name="Production Breakpoints"/> <EventID>4166</EventID> <Level>1</Level> <Task>0</Task> <Keywords>Keywords</Keywords> <TimeCreated SystemTime="2021-04-28T21:20:55Z"/> <EventRecordID>192925484</EventRecordID> <Channel>Application</Channel> <Computer>webwk000003</Computer> <Security/> </System> <EventData> <Data>IfFailRet(pNamedPipe-&gt;Read((BYTE*)&amp;controlRequest, sizeof(SnapshotHolderControlStruct))) failed in function CSnapshotHolder::HandleNewPipeConnection: -2147024787</Data> </EventData> </Event> </Events>

I also attempted to get the stdout log. Unfortunately this file was always empty.

[JohnDoeKyrgyz]

This is a symptom of this issue: Zaid-Ajaj/Fable.Remoting#226

[travis-leith]

I had this issue and all I did to fix it was make sure the app ran in Azure as 64bit.

[teknikal-wizard]

I can confirm that switching the app service to 64 bit gets around the issue. Unfortunately, this requires a Basic or higher plan (i.e. the default Free or even the Dev tier are restricted to 32 bit).

[isaacabraham]

I wonder what it is about 64-bit that fixes the issue - why are we suddenly coupled to that? cc: @Zaid-Ajaj @theimowski Also looping in @eiriktsarpalis since it seems related to the TypeShape / Remoting issue.

I really, really want to avoid forcing people onto paid plans to use this on Azure.

[travis-leith]

I think for me it was because some dependency I had only supports 64 bit. I didn't look into it further once I had a solution though.

[isaacabraham]

@travis-leith Even an empty SAFE 3 template suffers from this issue.

[teknikal-wizard]

I just looked at the fix for the typeshape thing the other day and it mentions using an int64 - is that the problem? Zaid-Ajaj/Fable.Remoting#228

[isaacabraham]

Pretty sure that's not the issue.

[kerams]

@JohnDoeKyrgyz, @travis-leith, what is the version of Fable.Remoting.MsgPack that you see in your packet.lock?

[travis-leith]

    Fable.Remoting.Client (7.2)
      Fable.Browser.XMLHttpRequest (>= 1.0)
      Fable.Core (>= 3.1.5)
      Fable.Remoting.MsgPack (>= 1.6.2)
      Fable.SimpleJson (>= 3.17)
      FSharp.Core (>= 4.7)
    Fable.Remoting.Giraffe (4.15)
      Fable.Remoting.Server (>= 5.13)
      FSharp.Core (>= 4.7.2)
      Giraffe (>= 4.1)
    Fable.Remoting.Json (2.13)
      FSharp.Core (>= 4.7.2)
      Newtonsoft.Json (>= 12.0.2)
    Fable.Remoting.MsgPack (1.7)
      FSharp.Core (>= 4.7.2)
      TypeShape (>= 8.0.1)
    Fable.Remoting.Server (5.13)
      Fable.Remoting.Json (>= 2.13)
      Fable.Remoting.MsgPack (>= 1.7)
      FSharp.Core (>= 4.7.2)
      TypeShape (>= 8.0.1)

[travis-leith]

Incidentally, I was getting some weird serialization errors that were resolved by turning off msgpack.
I have not yet reported the errors since I need to come up with a non-confidential example payload.
The error was something like "Expecting Int32 at position 55, but the data contains an array."

[kerams]

@travis-leith, OK, so that's an old version of Remoting.Server that still depends on the TypeShape package. If you update to the latest, you should not see this problem anymore, UNLESS you also use binary serialization, because Remoting.MsgPack still depends on TypeShape.

At the moment I am not aware of any serialization bugs besides missing char support, so it would be great if you could narrow down the problem and open an issue. Problems like this can also pop up when you have mismatching MsgPack versions on the frontend and backend (like when you update dependencies in your solution, but only deploy a new backend), since the representation of data may occasionally change between versions.

[JohnDoeKyrgyz]

@JohnDoeKyrgyz, @travis-leith, what is the version of Fable.Remoting.MsgPack that you see in your packet.lock?

Fable.Remoting.Client (7.9)
Fable.Browser.XMLHttpRequest (>= 1.0)
Fable.Core (>= 3.1.5)
Fable.Remoting.MsgPack (>= 1.9)
Fable.SimpleJson (>= 3.19)
FSharp.Core (>= 4.7)
Fable.Remoting.Giraffe (4.21)
Fable.Remoting.Server (>= 5.19)
FSharp.Core (>= 4.7.2)
Giraffe (>= 4.1)
Fable.Remoting.Json (2.16)
FSharp.Core (>= 4.7.2)
Newtonsoft.Json (>= 12.0.2)
Fable.Remoting.MsgPack (1.9)
FSharp.Core (>= 4.7.2)
TypeShape (9.0)
Fable.Remoting.Server (5.19)
Fable.Remoting.Json (>= 2.16)
Fable.Remoting.MsgPack (>= 1.9)
FSharp.Core (>= 4.7.2)

[kerams]

@JohnDoeKyrgyz, and you encountered the problem in Azure with these versions and without using binary serialization? That would be troubling.

[travis-leith]

@kerams the problem occurs even with the unaltered template, right?

[kerams]

@travis-leith, that would be expected because unless you update after using the template, you're stuck with an older version of Remoting without a particular fix.

[travis-leith]

Does that mean that when the .net 5 version of the template comes out, it will not have this problem since it will have the correct version of Remoting?

[Zaid-Ajaj]

Does that mean that when the .net 5 version of the template comes out, it will not have this problem since it will have the correct version of Remoting?

@travis-leith You can wait for the new template with net5.0 but nothing stops you from simply updating the Fable.Remoting.* packages to latest which we believe should solve this issue

[theimowski]

I think we can close the issue now?