« Back to home

How portable is ASP .NET Core 1.0?

Daj się poznać

In the previous post, I wrote about accessing a protected API controller being authenticated with id tokens obtained from Google. I created my application on Windows in Visual Studio because I needed the helping hand of dotPeek to see what was going on inside code that is not mine. In this post, I’ll write what happened when I ran this application on Ubuntu.

After I pulled my project from github, I restored all packages using dnu restore and I ran the application. The project compiled and ran without any trouble. I obtained a token from Google and I clicked the Protected button and I saw this on the screen:

Error after Protected

I looked at the console where my app was running I saw the same error.

Could not load type asymmetric signature provider

I thought that the tip on how to solve this problem was included in this line: Could not load type 'System.IdentityModel.Tokens.AsymmetricSignatureProvider'. I googled this error and I found this RSACryptoServiceProviderProxy crashes on. A quick look at this page gave me a clue that there are differences in the cryptography between Mono and .Net on Windows. I am not going into details here, but what’s important is that at the time of writing this post, this issue was still ongoing. I tried a different version of package Microsoft.AspNet.Authentication.JwtBearer, which was 1.0.0-beta8 but in this package extension method UseJwtBearerAuthentication didn’t exist.

Okay, this was on Mono but what happened on coreclr? I switched my execution environment to coreclr using the command dnvm upgrade -r coreclr. This command upgraded my coreclr version and set it as the default runtime version. dnvm list gave me an output like this:

dnvm list ouput

Then I ran the application and obtained a token from Google by clicking Get Token and finally I clicked the Protected button and I saw this:

Unable to load dll Ncrypt

This line: * ‘System.DllNotFoundException: Unable to load DLL ‘ncrypt.dll’* seemed to be the key part of this error for me, so I googled it. The first search result brought up this issue on github. This issue seemed to be resolved but it is added to milestone:RC2 so probably the next version will have this error fixed.

In conclusion, what does the portability of ASP .NET Core applications really look like? In the case of Windows, everything works perfectly. On Linux (Ubuntu) it didn’t work. You can read above about what exactly didn’t work. Yes, I could hack it and work around these errors, for example, by implementing my own SignatureProviderFactory, but I am quite sure that the .Net Team will do this better than me in the near future. It’s only a matter of time for ASP .NET Core to work the same on all platforms. You can find out more about it here, but for now it is still bleeding edge and bleeding edges hurt.

Related posts:


comments powered by Disqus