Using newer ES6 features in Node

Posted by on Jul 8, 2016 in JavaScript, WebDev

If you’re writing Node and want to use some of the newer ES6 features then you may have an issue running some of the newer features that haven’t made it into the V8 engine integrated with your specific version of Node. I came across this recently when using the new default parameters feature. Using the latest stable version of node (4.4 at the time of writing), the following code was throwing an error at runtime: function doSomething(param1, param2, callback=()=>{}) { //Do stuff } 123 function doSomething(param1, param2, callback=()=>{}) {  //Do stuff} Essentially I wanted the callback parameter to be optional so that I could supply it if I wanted to and it would get invoked, but not throw any errors if not. Using default parameters meant I didn’t have to clutter up my code with lots of null checking and ugly if statements. This is a pattern I use quite a lot in ES6 and feel it leads to much cleaner code. Node was complaining of the unexpected token callback=() as it didn’t understand the assignment of the anonymous function to the callback parameter (i.e. the default value). After a bit of digging it became clear that there were two ways around this problem, both of which worked for me. Initially I sidestepped the issue by using the new harmony feature flags, which turns on the experimental features in unsupported versions of v8. Thus, in my case simply adding the default-parameters flag worked around this problem: node --harmony-default-parameters index.js 1 node --harmony-default-parameters index.js However, the harmony feature flags aren’t really recommended as its putting alpha level code into the fray. The longer term solution (and the route I took) was to upgrade node to the newest version. Again, at the time of writing this is 6.3.0 which has a much, much broader level of ES6 compatibility due to its newer build and newer version of V8. Problem solved. ES6 and...

Read More »

MetadataException: Unable to load the specified metadata resource

Posted by on Jun 29, 2016 in, MVC, PowerShell

I recently came across an error in a .net application where the message was as follows: MetadataException: Unable to load the specified metadata resource 1 MetadataException: Unable to load the specified metadata resource It took a fair bit of digging but eventually found the underlying cause. My suspicions were that it was DB related due to the point in my application that it was failing. However, where/why I wasn’t sure. After a while I discovered the source of the problem. Entity Framework, in its wisdom, breaks down an EDMX into three constituent parts, a CSDL, SSDL and MSL. These are all strongly typed to the same namespace as your EDMX and thus the Entity Framework connection string will start something along the lines of: metadata=res://*/|res://*/|res://*/; 1 metadata=res://*/|res://*/|res://*/; Where is obviously the namespace that corresponds to your EDMX. If these do not align, then Entity Framework will not know which embedded resource to load your EDMX from and thus you will. In my case, I was transforming the connection string using Powershell to add in some environment specific variables and mistakenly changed the resource names, hence this error. Therefore, if you run in to the problem of Unable to load the specified metadata resource, be sure to check this...

Read More »

Early thoughts on core

Posted by on May 27, 2016 in, MVC

The more I play with core (RC2 at time of publication) the more I’m liking what I see. I still don’t see a use case for me on OSX or Linux yet, so the portability isn’t a massive thing for me. In my mind the windows use case for is fantastic and licence costs aside the setup and configuration is so simple on Windows I can see little benefit from venturing elsewhere. Application settings There are still things I don’t particularly like about core, including recent changes. One of these is accessing settings file. In ‘current’ (must be careful not to call it ‘old’ or ‘legacy’) is the ConfigurationManager class made accessing your settings from web.config both simple and succinct. Now though, web.config is no more. Why, I’m not entirely sure. Maybe it’s the flexibility of having multiple configuration sources or not mixing application settings with its configuration. Regardless, you’ll now almost certainly be storing your configuration settings in a JSON file, with appsettings.json seemingly becoming the convention. In early releases of core this was similarly easy to access settings from a JSON file for example simply by using the IConfigurationRoot dictionary (provided you added the source in the startup configuration). However, in the latest builds (RC2 onwards) this has changed. You now need to strongly type your settings via POCO classes and access these settings through the IOptions class. Once its set up and configured the usage is quite straightforward but it’s a lot of setup and maintenance IMO. Every new setting requires adding to the JSON file AND to the corresponding POCO class. State of flux So at the time of writing core is at release candidate 2 stage. However, there are still some big, big changes going on. The underlying .net runtime has gone though a massive shift of late with the introduction of the much cleaner dotnet CLI. This is a big step forward IMO but not something you would normally expect in release candidates. This still feels much more beta than RC to me so be mindful that there are still lots of breaking changes going on. Another example of this is that having followed the recommended guidance on setting configuration settings access up the “new way” I was still hitting issues. Turns out that a namespace shuffle occurred in the core libraries and was largely undocumented until a couple of days ago ( Following the new namespace import and package restore and things are now working fine. As I say, core is still moving forward at a rapid pace with both minor and major changes causing breakage for the developer and at the same time invalidating lots of the already limited documentation. Sending email Another hurdle is the lack of System.Net.Mail in core. This means the tried and tested way of sending email is (at the time of writing)...

Read More »

Obtain scenario name and tags in Specflow test

Posted by on May 4, 2016 in, WebDev

I was recently tasked with obtaining the tag name(s) and title of a Specflow feature within its step definition file (C# code). It turns out this is quite simple to do and exposed naturally within the step definitions through the TechTalk.SpecFlow.ScenaroContext class. ScenarioContext.Current 1 ScenarioContext.Current exposes the current scenario context, from which a ScenarioInfo property is declared. Quite conveniently, this class definition contains a string array of tags and the title, all neatly wrapped up in a single, consice class: namespace TechTalk.SpecFlow { public class ScenarioInfo { public ScenarioInfo(string title, params string[] tags); public string[] Tags { get; } public string Title { get; } } } 12345678910 namespace TechTalk.SpecFlow{    public class ScenarioInfo    {        public ScenarioInfo(string title, params string[] tags);         public string[] Tags { get; }        public string Title { get; }    }} Therefore, anywhere in your current stepdefinition you should be able to get the title and the tags using: var title = ScenarioContext.Current.ScenarioInfo.Title; var tags = ScenarioContext.Current.ScenarioInfo.Tags; 123 var title = ScenarioContext.Current.ScenarioInfo.Title; var tags = ScenarioContext.Current.ScenarioInfo.Tags; Easy as...

Read More »

Starting mRemote with a new config file path

Posted by on Aug 5, 2015 in Other

I love mRemote as a means of managing my RDP sessions but do find it somewhat flaky regarding the connection file. I’ve had connection files become corrupt on a number of occasions (hint: back up this file now if you haven’t already and get in the habit of backing it up every time you change it!) and recently it bombed out for a different reason. As I use OneDrive more and more for storing my cloud data I restructured some of my folders without considering the implication of the apps that rely on those files. mRemote was one of those and the config file was moved from its original directory in to a sub-directory. This caused the rather hostile situation of a start-up error: The startup connection file could not be loaded. C:\Users\Lee\AppData\Roaming\mRemoteNG\confCons.xml Input string was not in a correct format. In order to prevent data loss, mRemoteNG will now exit. And there was no option to start with a blank connection file or just load the UI and let me locate the file. Not a great user experience. Turns out the solution is quite simple though – the config file can be passed as a command line argument and starting the app this way fixed the issue “permanently”: “C:\Program Files (x86)\mRemoteNG\mRemoteNG.exe” /c:”C:\OneDrive\path\to\config.xml”...

Read More »