Some time ago I was searching a touch display for a project of mine. The requirements were 7 inch in size, capacitive touch digitizer and at least a resolution of 800x480px. I figured out Waveshare’s “7 inch HDMI LCD (B)” would be the perfect match. And I was thrilled that not only it was not only relatively cheap, but they got it right and (so the claim) implemented “fully valid” HID protocol (their shop still states “When work as a computer monitor, supports Windows 10/8.1/8/7, five-points touch, and driver free”).
When I received the display, everything was working out of the box with my Raspberry Pi 2 running on Windows 10 IoT. Then the Anniversary Update came and that’s when things got weird. Over-night my slightly laggy touch display turned into one that responded to scroll movements, but I could hardly get a “click” to trigger. Later I found that thread over at the MSDN support forums: Waveshare 7 inch display doesnt work on windows 10 iot core
After a few days of discussion Microsoft acknowledged that there was some change in the HID report processing pipeline, which now discards HID reports that are malformed. The advice was to contact Waveshare to see what they could do about the issue. Long story short, I never got a satisfying answer. So I decided to fix it on my own.
You might remember I published a Nuget package to help integrate NLog with OWIN back in December 2014. And it worked great so far! A few weeks ago I got a notification from Github that my name was mentioned in some issue. Long story short, the main NLog maintainer and I decided to move Pysco68.Owin.Logging.NLogAdapter over to the NLog organization to give it a bit more visibility.
So there we go; from today on, you should use NLog.Owin.Logging to get OWIN and NLog together. Oh, and there’s a new Nuget package too: NLog.Owin.Logging@Nuget.
The usage remains the same:
Hello folks – just a quick post!
I finally found the time to publish a workaround I wrote back in May this year. I was hacking a fully automatic irrigation system (garden stuff you know ^^) and because I had to do that really quickly (before leaving for vacation) I decided go the route of a known framework: OWIN, ASP.NET WebAPI 2, NOWIN (as a host), Identity 2.0, EntityFramework, MariaDB, a good HTML5 stack… etc…
Well mostly a known framework; I had to run on a Raspberry and Microsoft wasn’t quite as ready with Windows 10 IoT as I’d needed it… So it was a quick decision to stick with Raspbian and Mono. Which by the way work out great. At the time of writing my little application has over 140 days of uptime! – Yay –
I’ll probably write more about the whole project in the next months!
Anyhow I faced the problem that the MySQL Connector/NET is *still* (I posted the bug on November 7th 2014 – Bug Ticket: #74726 EF migrations fail on long foreign keys) having issues with code first migrations, long entity names and foreign keys… and as I really lost any confidence that ****** is going to fix that any-time soon I decided to do it on my own…
Tl;dr: You can use NTLM authentication without relying on IIS or HttpListener in OWIN projects by using my OWIN autentication middleware: more information on my Github project: Pysco68.Owin.Authentication.Ntlm middleware. It’s working flawlessly with ASP.NET Identity 2.0! And there’s a Nuget package too!
As you may have noticed, I’m relatively busy these days with things like OWIN and surrounding technologies. All there shiny and new things that just fit together so well. And then you have customers just requiring plain old things like NTLM for their latest shiny intranet application.
On a recent machine-to-machine communication scenario I needed to enable secure push messages. The server side of the project was plain ASP.NET Web API 2 (on OWIN – I just love it) so dropping in SignalR and a few hubs was done in minutes. The tricky part was that I was using the Hawk authentication scheme to secure the access (and I was very happy on how it worked out so far). So no reason to change anything about the global setup if it wasn’t for the .NET SignalR client library not supporting Hawk out-of-the-box.
But luckily SignalR sources can be crawled through easily over at github (https://github.com/SignalR/SignalR). And even more luckily I found that it would be no more that a few lines to wire it up with Thinktecture’s Hawk implementation (Thinktecture.IdentityModel.Hawk on Nuget).
So there you go, my latest, greatest Nuget packages is: Pysco68.SignalR.HawkHandler.
BTW. there’s some news about that topic: My NLog OWIN adapter went “official”
While playing around with OWIN, WebAPI 2 and the other new kids I was missing a logger factory for my favorite logging framework: NLog! And I wouldn’t be a good software engineer if I didn’t wire this up in a nice tiny library.
There you go: Pysco68.Owin.Logging.NLogAdapter on GitHub
And to make it a breeze I built a Nuget package for this one! That means that you can now use NLog as logger for your next OWIN project just by doing this:
Voila! If you’d like to customize the log-level translation table just take a look at the Github page!
Note: this is not a logging middleware! If you want some of those Google is your friend. The log factory (it’s an implementation of Microsoft.Owin.Logging.ILoggerFactory in fact) does provide an implementation of ILogger that wraps arround NLog.There’s some pretty good information about the architecture at Tugber Kugurlu’s blog / introduction to OWIN Logging.
I really hope you enjoy this one! Leave a comment if you have any question or suggestions! Contributions are welcome, just fork and create a pull request, I’ll review it for sure!
Hello again! Christmas’ approaching with giant steps and I finally have some free time to write again. After sitting on my desk for a short while, here are the remaining steps for the restoration of the Dual CS 606 record player. For those of you who haven’t read the first part: Dual 606 record player – Restoration (part 1).
In this second part we will focus on getting the electronics up and running again. This involves replacing all the capacitors and checking/cleaning the pots, switches and finally checking solder joins.
…I finally made it: ASP.NET Identity 2.0 running with MariaDB! It was more difficult than I expected it to be. I’ve been using EntityFramework with MySQL successfully in my day-time job for over two years now. As I was starting a small toy project at home last week I decided to go the easy route: ASP.NET Web API 2 running in an OWIN application. That was the perfect opportunity for giving ASP.NET Identity 2.0 a shot – instead of rolling my own authentication framework.
I still believe that this choice isn’t bad at all, but I underestimated the cost of getting it to run in a heterogeneous environment (read: not everything is Microsoft technology).
Surprisingly (to me – but hey!) Microsoft is providing an example of how to use MySQL and EntityFramework 6 as a storage provider for ASP.NET Identity 2.0. Sadly the example isn’t working out of the box – at least not in my setup. One aspect is that when they wrote the tutorial the MySQL Connector/NET wasn’t supporting EF Code-first migrations as well as it does nowadays. The second issue was the primary keys in the ASP.NET Identity tables being too long for MySQL.
If you read the very first article on this blog you might have seen that I’m rebuilding old record players. And lately I just started over with my third one; it’s a 1980 Dual 606. Back then it was a mid-range player, but much of the hardware was taken unchanged from the high-end equipment, most notably the drive-train (more on that later).
On a first sight the device was in a very good condition when I received it, but there were some issues with the electronics – rather common for devices this old – which had to be fixed. The first part of this series of articles is about technical details and how to break the turntable open. Continue reading