Update (3 Oct 2018): Thanks to the beloved-by-community Jon Galloway, I can finally connect with the engineers working on the library. Hopefully, the team can push out a fix soon.
Update (13 Oct 2018): Microsoft team has quickly release version 2.0.1 with proper fix for the issue. Bravo for the team!
I have been using Azure Notification Hub for a very long time to send push notifications to my UWP apps on Windows 10. Since the introduction of .NET Core 1.0, I have gradually been moving my projects from .NET Framework to .NET Core. However, Microsoft.Azure.NotificationHubs was always the blockers due to the lack of support for .NET Standard.
Tl;dr version:
- 2.0.0-preview1 and preview2 have issue sending WNS Raw message.
- After 8 months, 2.0.0 was released with the same issue.
- There was no place to report the issue.
- There was no source code.
- The fix is only 1 LOC, but I spent much more time to make the decompiled code compile back.
- And now I have still no way to report the issue nor contribute the fix.
Now is the lengthy version. 10 months ago, I was so happy seeing 2.0.0-preview1 version of the SDK on nuget with support for .NET Standard. Sadly, it broke WNS Raw message with the following error:
|
1 2 3 4 |
System.ArgumentException : The content type for a 'wns/raw' notification must be 'application/octet-stream'.TrackingId:65230d32-b4a8-4859-8746-524947420109_G0,TimeStamp:9/20/2018 5:21:44 PM at async Microsoft.Azure.NotificationHubs.NotificationHubClient.SendRequestAsync(??) at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at async Microsoft.Azure.NotificationHubs.NotificationHubClient.SendNotificationImplAsync(Notification notification,String tagExpression,String deviceHandle,CancellationToken cancellationToken) |
My code worked perfectly with SDK 1.x versions, so I guessed there was just a minor bug in the preview. I tried to send a bug report but I cannot find the repository anywhere, so I patiently wait.
2 months later, 2.0.0-preview2 was available on nuget. I updated the library and tried again, but there is no improvement on the issue. I thought of implementing the whole NotificationHubClient by myself as it should be just a wrapper of the REST API, but I did not manage time to try that yet. Also, I held the hope that Microsoft people will fix that for the release.
Then came 8 months with no update for the library, and finally 2.0.0 is released. Again I updated my nuget reference and got disappointed again with the same error. I tried again at finding the source code, considering Microsoft, especially Azure, is very keen on open-source now. Strangely, I cannot find the source code of that Notification Hubs SDK anywhere, and also no place to report issue. I tried to use the contact email in nuget, but no one replied me. This is really sad!
I decided to put more effort on finding a workaround, considering Microsoft is not going to do anything about this issue. I first tried to add “Content-Type” “application/octet-stream” into WindowsNotification.Headers, which didn’t help at all. I got a new error:
|
1 2 3 4 5 6 |
System.InvalidOperationException : Misused header name. Make sure request headers are used with HttpRequestMessage, response headers with HttpResponseMessage, and content headers with HttpContent objects. at System.Net.Http.Headers.HttpHeaders.CheckHeaderName(String name) at System.Net.Http.Headers.HttpHeaders.Add(String name,String value) at async Microsoft.Azure.NotificationHubs.NotificationHubClient.SendNotificationImplAsync(Notification notification,String tagExpression,String deviceHandle,CancellationToken cancellationToken) at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at async ProjectStudio.Api.Logics.NotificationHubLogic.SendWindowsRawNotificationAsync(String content,String tags) |
Apparently whatever I put in WindowsNotification.Headers are added to web request headers, which is wrong for Content-Type. I then tried to set WindowsNotification.NotificationType to “application/octet-stream”, which didn’t help either.
After a couple more attempts to find the repository of the library ended up nowhere, I turned to ILSpy for to decompile the library and Fiddler to see the raw HTTP request. The problem becomes apparent: the library set the HttpContent by
|
1 |
request.Content = new StringContent(notification.Body, Encoding.UTF8, notification.ContentType); |
Since it is string content, the encoding is appended to the content type, creating Content-Type: application/octet-stream; charset=utf-8, which breaks some validation in Azure Notification Hubs for WNS Raw.
The fix is simple: we can overwrite the content header
|
1 |
request.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue(notification.ContentType); |
However, that is actually the easy part. Since the library is not open source, I had to extract a decompiled version, added in that one line and fixed so many unrelated issue to make it compile. Even worse, I have no way to submit the fix back or even just report the bug.
I really hope this post would help somebody and hope that some Microsoft guys would see this post and do something about this bad situation.