Posts

Showing posts from March, 2018

WebUSB - An unexpected update...

Image
In January at my new(ish) user group Momentum Meetups , I presented on "Reaching out beyond the Chrome" (although suffering from food poisoning so I was definitely going green at points!). It included  WebUSB and WebBluetooth . I was excited by how powerful it was and even had a colleague present something we had been prototyping in out work place. During the talk I mentioned security and how it had been designed so it only works on https and there's a permission model where you have to approve the device before it can be used. Unfortunately this week it came to light that Authentication devices could be bypassed via USB. These devices are a great way of proving you are who you say you are on the web beyond basic 2FA text's or applications. So being able to be able to bypass them via WebUSB is a big deal :( My Original Security Slide A few days later Google then disabled WebUSB by default effectively killing it off until such a time where its made secure...

a different day a different msbuild issue...

Image
Recently I started working on a small tweak to an existing web project, its a small internal dashboard sort of thing nothing complicated about it. However after I started working on it I found I could no longer build the project it came up with: ): error CS1525: Invalid expression term 'throw' ): error CS1002: ; expected  error CS1043: { or ; expected  error CS1513: } expected : error CS1014: A get or set accessor expected : error CS1513: } expected  When I looked at the location of the build errors I could see some perfectly valid code, all be it C#7:  public IEnumerable<AttemptResult> Attempts { get => _attempts; set => _attempts = (value ?? Enumerable.Empty<AttemptResult>()); } Why would it not like the C#7 code, i'm in VS2017 it should all be correct, when I double checked the language setting under Advanced Build Settings it correctly had C# latest major version, so it wasn't a case the project had got pinned to a lan...

project.json doesn't have a runtimes section, add '“runtimes”: { “win”: { } }' to project.json within a .Net Class Library

Recently I've started experiencing weird build errors when switch branches on a product. Error : Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win": { } }' to your project.json and then re-run NuGet restore. It's a weird sounding error and the fact it mentions project.json makes it sound like a hangup from when .Net Core and Standard were using project.json files before they became .csproj files again. My first thought to resolve this is always try a clean and build, particularity when swapping branches things could get left hanging around but this doesn't work. I took a closer look at the projects affected and the cause is to do with one of the branches of our product. It's an early development branch of a new feature where the project has become .Net Standard 2.0 but also targets .Net 4.5, where as the support and main dev branch are still the full framework class libraries.  The cause is mos...