Click here to Skip to main content
15,868,141 members
Articles
(untagged)

My first exception caused solely by .Net Native

Rate me:
Please Sign up or sign in to vote.
4.67/5 (2 votes)
6 Nov 2015CPOL2 min read 8.3K   1   3
In a current project we’re developing a UWP application which, as you may or may not know, *requires* you to compile to .Net Native in order to submit to the store. No biggie, that hasn’t been a problem. Until now.

In a current project we’re developing a UWP application which, as you may or may not know, *requires* you to compile to .Net Native in order to submit to the store. No biggie, that hasn’t been a problem.

Until now.

 

We had a tester come to us with the app installed from the store yesterday reporting the app seized up and crashed upon their first click/tap within the app.

“INCONCEIVABLE!” we said.

No matter how hard we tried, Debug mode, Release mode, x86, x64, mobile, tablet, we couldn’t reproduce.

Until we turned on .Net Native tool chain in the project compilation options:

2015-11-06_1039

The second we did this, boom.

It left us scratching our heads but there was one thing we *had* added to the app recently that seemed like it could be the culprit:

SignalR.

We had a backend service which used SignalR to stream data to our app. The SignalR libs we were using are the ones from Microsoft: AspNet.SignalR (available on NuGet).

When we dug in to where and why the crash was happening, it was in this code:

if (_connection != null)
{
    _connection.Stop();

    _connection.Dispose();
    _connection = null;
}

turns out – only when in .Net Native – the call to .Stop() caused a NullReferenceException to be thrown from the bowels of the SignalR libs and, since the Stop() call is synchronous, it seized the app while the exception bubbled and percolated through before finally crashing the process.

How did we fix it?

Turns out it’s somewhat of a hack but hey, it works – at least until the SignalR folks on the AspNet team figure out how to play nice with .Net Native:

//Found that when compiled .NET Native that tearing down the connection can take 30 seconds and
//result in huge exceptions and failures.
//We are going to task this out.
Task.Run(() =>
{
    if (_connection != null)
    {
        try
        {
            //Give the connection 3 seconds to stop. If it doesn't, then just eat all exceptions and move on with life.
            _connection.Stop(TimeSpan.FromSeconds(3)); 
            //_connection.Dispose(); -- Sounds like Dispose is the same as _connection.Stop, no need to double up on the calls.
            //^ Left this here as a tombstone for future people. If there are bugs, feel free to use Dispose, but then you don't get the
            //nice timeout parameter that Stop provides.
        }
        catch
        {
            //When we compile release / .NET native the connection object behaves erraticly and can throw exceptions.
        }
        _connection = null;
    }
    _hubProxy = null;
});

 

The comments basically explain the approach, but to spell it out:

  1. Stop your connection on a background thread/task so the UI isn’t locked while Stop() executes (remember it’s synchronous).
  2. Eat any exceptions that might occur during stop; we at least were going to be throwing the connection away anyway.
  3. Provide a timeout for the Stop() call so it doesn’t try and seize your UI while it’s executing.

After doing this, our app behaved exactly as it needed to with respect to our usage of our SignalR backend and its connection creation & disposal points.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior)
United States United States
I'm a Sr. Software Engineer in the Seattle area primarily focused on serverless technologies in the cloud. In my free time I enjoy hiking & other adventures with my family around the Puget Sound and the country! You can find out more about me at my homepage: http://bc3.tech/brandonh

Comments and Discussions

 
Suggestionvery broad trap Pin
Israel Alonso9-Nov-15 6:53
Israel Alonso9-Nov-15 6:53 
GeneralRe: very broad trap Pin
BC3Tech9-Nov-15 7:54
BC3Tech9-Nov-15 7:54 
obviously this is an understood caveat.

the good news is I've actually fixed the underlying problem for the SignalR team and submitted a PR for it.

Hopefully they'll pull it in soon.
http://bc3.tech

QuestionSignalR Hub Pin
tommasuth9-Nov-15 5:00
professionaltommasuth9-Nov-15 5:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.