Blog
Welcome to my blog. Recent posts:
Problems linking Azure and VSTS?
I recently hit a minor road-block when attempting to link a VSTS account to an Azure account to do automated deployment upon checkin to a given branch. For some reason Azure simply would not “see” my VSTS account and therefore projects from the portal. After a little bit of searching online I found and followed this article on the Kudo blog. Specifically it states that you need to be at least a project administrator, it must be GIT source controlled project and you need to check if you can create service hooks (to validate the given permissions). All of these were fine so I continued searching. I then stumbled upon this article which solved the problem for me. It seems you also need to be the project OWNER, which I was not. Thankfully, changing ownership is a doddle so I switched owners using the details in the post I just linked to and it still didn’t show up. Finally, I switched back to the old azure portal and tried linking my accounts there. Voila! It worked. Why the new Azure portal couldn’t see the VSTS account I don’t know, but as soon as they were linked in the old portal everything started working in the new one. It seems we may be stuck with two portals for a little while...
read moreSetting the deployed project in a multi-project asp.net core solution in Azure
If you deploy a single project asp.net core application to azure everything is about as smooth as it could be. A typical workflow would be to simply create a new web app, set the deployment source (e.g. your git repository) and everything is up and running in a few seconds. If, however, your solution contains multiple projects, how do you specify which project is deployed? Previously this would be done using Azure deployment scripts, but this is a needless effort for such a small task. Just look at the wiki for details on why you may want to avoid this. The preferred way is to specify an Application Setting in the Azure portal. The advantage of this is that you have no deployment code checked in to your source code repository and you can more easily toggle active projects both without deployment and between deployment slots. To do this we need to go to your web app in the portal, click App Settings and create a new App settings key called PROJECT with the path to your project file: However, while this works well with full .net framework applications that use .vbproj and .csproj solutions, at the time of writing asp.net core applications still use the soon-to-be-obsolete .xproj system. If you point your app setting to an xproj, you’ll get an error message in the console. A workaround to this is to update the setting to point to the directory of the solution you want to deploy, relative from the root of your source code repository. In .net core land, this is likely to be along the lines of [Solution name]\src\[project name]\ 1 [Solution name]\src\[project name]\ And you can verify this using the very, very handy console (found under development tools in your web app service list). Open the console and cd ..\repository 1 cd ..\repository and from there traverse your way to your folder containing your xproj. Copy that path (from repository onwards) and use this as the app setting: Redeploy your solution, and you should be up and running with your chosen project. Another benefit… Another nice benefit of this approach is that if you use deployment slots, you can toggle projects per deployment slots, making it exceedingly quick to switch projects just by doing a slot-swap in the...
read moreMigrating to TypeScript from ES2015 for AWS Lambda
I was recently building an skill for the Amazon Alexa platform (think Amazon Echo, Fire tablets, Echo Tap etc). Like anyone writing JavaScript today I naturally levitated toward some of the syntactic goodness that ES2015 offers – arrow functions, let variable scoping, string literal templating, default parameters etc all of which make JavaScript a much, much nicer language (and much, much closer to C# incidentally which is where the language seems to be heading long-term looking at current and new functionality. Alas, I digress!). I had the skill up and running locally (bridged via an Express.js node front end for testing) and everything was working well. Then it came the time to upload my skill to the amazon developer portal and migrate my function to AWS Lambda. This is where the fun started – it turns out Lambda uses a fairly dated version of Node.js that doesn’t support much of the ES2015 specification. This left me faced with two options – strip out all the ES2015 code and rewrite using vanilla JavaScript or make use of our friend, Typescript. To be honest I should have gone down the TypeScript route from the offset; in hindsight I’m not sure why anyone would write straight JavaScript nowadays when the TypeScript transpiler does such a great job of both supporting new functionality and also outputting compliant ES5 code. The task of migrating from JavaScript was as easy as 1-2-3: Rename all my .js files to .ts Install tsc from the command line (npm install –g tsc) and create my tsconfig.json with the list of files in my project Run typescript in watch mode (tsc –w) to get it to watch for changes to save (my lazy hands) having to recompile manually Once this was done I was free to do nothing more and I already had fully “Lambda compliant” JavaScript that I could use. However, the TypeScript compiler can do so much more for me, so I spent a little time going through my code adding in types to all my parameters, created an object interface so TS knew the type of data I was passing around on properties on the object (this also greatly improved Intellisense in VS Code I might add) and pulled down some typings for the third party libraries I was using. Migration was such a smooth and painless experience and I’m now in a much better place than I was prior to the conversion. I have compile time type checking, I get to use the much more elegant and succinct ES2015 syntax and I have a much better development environment through the “knowledge” TypeScript now has about my...
read moreIIS: There was an error when performing this operation
I recently started setting up a new dev box and a couple of solutions (bound to IIS) simply would not run. In the browser I was getting a 500.19 error while even attempting to open the configuration for the website in IIS greeted me with the completely unhelpful message of: “There was an error when performing this operation” While this message couldn’t be any less useful if it tried, it hinted that the problem was with IIS rather than the website. My initial thoughts were permissions, so after ensuring the IIS_IUSR account had access to the web.config file I next attempted to ensure all additional modules were installed. The missing IIS rewrite module has bitten me I the past so I double checked that was installed – without it this is exactly the error message you would see, which led me to believe another missing IIS addon was at fault. The steps I took to debug this though was to section by section go through my web config removing each section and attempting to load the site and/or let IIS parse the config. When I removed the section pertaining to initialization optimisation this fixed the issue and I immediately remembered that this dependency was added a fair while ago, so much so that I completely forgot about it. Voila, installing the missing module fixed the problem and the site worked fine, plus IIS could now parse the configuration...
read moreUsing newer ES6 features in Node
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 moreMetadataException: Unable to load the specified metadata resource
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://*/Your.Namespace.com.csdl|res://*/ Your.Namespace.com.ssdl|res://*/ Your.Namespace.com.msl; 1 metadata=res://*/Your.Namespace.com.csdl|res://*/ Your.Namespace.com.ssdl|res://*/ Your.Namespace.com.msl; Where Your.Namespace.com 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 moreEarly thoughts on asp.net core
The more I play with asp.net 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 asp.net 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’ asp.net (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 asp.net 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 (https://github.com/aspnet/Announcements/issues/180). 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) not currently available. That said, there are alternatives which are easily substitutable, including MailKit. A good overview of Mailkit using core can be found on Steve Gordons blog: http://stevejgordon.co.uk/how-to-send-emails-in-asp-net-core-1-0 Positives Despite the above I am enjoying working with aspnet core. I like the changes to the dotnet CLI, the new startup configuration is nice and the ‘DI everywhere’ approach is very powerful (and beautifully executed with much greater simplicity than...
read moreObtain scenario name and tags in Specflow test
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 moreStarting mRemote with a new config file path
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 moreWhat is the Shadow DOM?
Shadow What? I’ve seen lots of queries on SO and various programming forums regarding the Shadow DOM. It seems lots of developers know that it exists, but many of those do not understand its purpose or significance. Moving forward, Shadow DOM is going to play a significant role in web development, not least as a core part of the web components specification. So What is it? At its highest level, the Shadow DOM is an emerging standard that allows you to encapsulate content (not just HTML) from the main document. This means you can ‘embed’ styles and markup completely decoupled from the rest of the web page and not have to worry about naming collisions, JavaScript conflicts or other quirks commonly found on large pages that use multiple frameworks from sources. So what is the problem? Imagine, if you will, a fancy all-singing, all-dancing video player. This reusable component if made available on the web for inclusion on your page (or even the native HTML5 video player supplied by the browser vendor). There are few scenarios where you would want other styles on the page to affect the core elements of the player (e.g. play/pause button) and you don’t want to have to worry about elements on your page conflicting with that of the video player. This is a very real worry but this is exactly the kind of problem the Shadow DOM is intended to solve. How does it work? At a simple level, with Shadow DOM any element can have a new node called the shadow root. This is the isolation boundary assigned to that individual element. The hosting element becomes the shadow host. This isolation provides great protection but also allows you to access the parent document via JavaScript so other parts of the page remain accessible (e.g. form controls) Can I start to use it? At the time of writing, we’re some way from full browser support. There are polyfills available (e.g. platform.js (https://www.polymer-project.org/0.5/docs/start/platform.html)) but as always, check the status on CanIUse.com for up-to-date...
read more
I'm a gadget loving code-junkie who loves to program, create websites and try out new stuff. Married, with two young daughters I am also a keen marathon runner and fitness enthusiast.