Problems linking Azure and VSTS?

Posted by on Apr 6, 2017 in Azure, Cloud

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 More »

Setting the deployed project in a multi-project asp.net core solution in Azure

Posted by on Nov 16, 2016 in Asp.net, Azure, Cloud

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 More »

Migrating to TypeScript from ES2015 for AWS Lambda

Posted by on Oct 12, 2016 in AWS, Cloud, JavaScript

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 More »

Enabling RDP on a Linux instance running in Azure

Posted by on Dec 30, 2014 in Azure

This post is a quick instruction on how you can enable the RDP protocol in an Azure linux instance. Why would you want to do this? Well, although you’ll probably want to SSH into the box for the majority of times, there are instances where GUI access is handy. If, like me, you like to consolidate all your RDP session (I personally use the excellent mRemoteNG ) then having this enabled is useful. Thankfully, getting RDP working on an Azure Linux instance is trivial. In my case, I’ll be using Ubuntu 14.04: Update apt-get to make sure your sources are up to date. If you don’t do this then you’ll get 404 errors in the next step sudo apt-get update 1 sudo apt-get update Once your repository is fully up to date, you can install a desktop. I’ll stick with the default, Ubuntu Unity. I’m not a massive fan of Unity but given the little time I’ll spend in here, it will suffuce. sudo apt-get install Ubuntu-desktop 1 sudo apt-get install Ubuntu-desktop This will take several minutes, so go make a coffee. Once you have a desktop environment installed, you can enable RDP: sudo apt-get install xrdp 1 sudo apt-get install xrdp The last thing to do is to open the RDP port on the Azure firewall. By default it isn’t enabled, so log into the Azure portal, select your Linux VM, go to the endpoints tab and add RDP to the list of open endponts Virtual Machines > Your Linux Box > EndPoints > Add > Add standalone Endpoint > Remote Desktop 1 Virtual Machines > Your Linux Box > EndPoints > Add > Add standalone Endpoint > Remote Desktop Once that is done and the Azure configuration has been applied, you should be set to...

Read More »

Unable to open formatted failed request trace log files on an Azure VM

Posted by on Jul 13, 2014 in Asp.net, Azure, Cloud

I recently had a problem whereby I couldn’t view failed request trace logs on an Azure hosted VM. The XML would open, but the XSLT wouldn’t be applied which made the page unreadable. My first thought was that freb.xsl file was missing or corrupt somehow, but after deleting the containing IIS log folder, which causes IIS to regenerate the file it was clear this wasn’t the fault. After a bit of digging I came to the conclusion that it must be permissions based and stumbled upon this post. Even though I wasn’t getting the content blocked error message, the default internet security settings on azure VM’s are set to high. Therefore, to resolve this you (rather bizarrely) need to add the about:internet page to the trusted sites list: Internet Options Security Tab Click Sites Enter about:internet in the ‘Add this website to the zone” text box and click the add button Close IE and re-open the trce log XML I’m not really sure why about:internet specifically fixes this, but it worked for...

Read More »

Pushing from GIT to Heroku

Posted by on May 30, 2014 in Cloud, Other

Pushing from GIT to Heroku I recently attempted to publish a small node.js application from my local machine under source control using git, to Heroku (http://www.heroku.com). While this should have been as simple as entering: git push heroku master 1 git push heroku master I was met with the error: Permission denied (publikey) fatal: Could not read from remote repository. Public key issues are never good Public key issues are never good – even less so when the error message is prefixed with ‘fatal’ 😉 The error message seemed quite clear and explicit – it seems that my local public key didn’t match that on Heroku and thus I could not authenticate. To resolve this I deleted the existing public key in my .ssh folder (located at c:\users\\.ssh\ and generated a new one. From a command prompt: cd c:\program files (x86)\git\bin ssh-keygen.exe 12 cd c:\program files (x86)\git\binssh-keygen.exe when prompted for the path I put in the path to the .ssh folder as follows: Enter the file in which to save the key: c:\users\lee\.ssh\id_rsa I left the password blank as this is a private machine and I’m too lazy to re-enter the pass-phrase every session. This generated a new key for me. Adding to the local key store From there I needed to add the key into the local git keystore. This is needed to ensure that both Git and eventually Heroku, are using the exact same key. To accomplish this open up a bash shell (after you’ve installed git for windows you can right click any folder and select ‘Git Bash’) and enter: $ eval `ssh-agent -s` $ ssh-add 12 $ eval `ssh-agent -s`$ ssh-add note the back-tick (above the tab key!) not apostrophe’s and also notice the eval statement. ssh-agent alone will not work Assuming you didn’t rename your key when generating (id_rsa), ssh-add will look for the default key name in the default key path. If you did change the file name you’ll need to pass this in as a parameter. If it worked, you should be prompted with: Identity added: /c/Users/lee/.ssh/id_rsa Sync the keys with Heroku Now you have a brand new key added into your local git you can start migrating this to Heroku. If you have no other keys in Heroku, run the following commands from a command prompt: heroku restart heroku keys:clear heroku keys:add 123 heroku restartheroku keys:clearheroku keys:add Assuming all went well and the output of the last step was: Uploading SSH public key …done then you should be good to go. Executing heroku:keys 1 heroku:keys should show your newly created and uploaded key. Ready, set, go! Finally, git push herku master 1 git push herku master should now succeed and you’re good to...

Read More »