MongoDB 2.6 cannot be installed as a Windows service

I like applications that are distributed in ZIP files, because then it usually means that they don’t rely on the registry and all other kinds of nasty stuff that makes it hard to clean up afterwards.

But today, when I wanted to install the newest MongoDB 2.6 on a Windows server and I did the usual

in an elevated command prompt, nothing happened.

When I checked out the log file in e:\logs\mongodb\log.txt it said “–install has to be used with –logpath” – but I did specify the log path, I know you have to do that, and I always do that.

After trying this a few times, I thought: Well, until now I’ve done in-place upgrades of MongoDB whenever there was a new version, so why not just install 2.4 (which I know can be installed), and then replace the binaries with the 2.6 ones.

Which I did – and it worked!

wow-cool

So this is how you can install the current MongoDB version 2.6 as a Windows service, even though it seems to be a little off with its command line parameter checking.

PS: I just Googled to see if anyone else has experience this issue – it seems they already know about it + the workaround. Seems the 2.6 release was shipped a little too soon ūüėČ (PPS: We all do that sometimes…)

Using Azure to host the node.js backend of your Xamarin-based iOS app

TL;DR: This is how to tell Azure to host your node.js web service even though your repository contains .NET solution files and/or projects: Create an app setting called Project and set its value to the directory where your node app resides, e.g. src\Server – this is the argument that will make Azure decide to host your node.js stuff and not the .NET stuff.

This is not new – it’s how you pick a .NET project to host as well when your repository contains multiple hostable .NET projects, but when it’s .NET you point to a project file instead of a directory.

Do NOT be fooled by GitHub issues mentioning setting the SCM_SCRIPT_GENERATOR_ARGS app setting to --node – doing that will not work together with the Project setting!

I wrote this blog post because it took me quite a while to figure this seemingly obvious thing out, mostly because I got fooled by various red herrings around the net referring to the aforementioned Kudu setting.

Long version ūüôā

Lately, I’ve been tinkering a bit with Xamarin Studio, trying to get a little bit into building a simple iPhone app.

My app needs a backend, which will be function as a mediator between the iPhone app and another backend, allowing me to

  • tailor the service to my iPhone app, trimming the API for my needs, and
  • not worry too much about having to update the iPhone app everytime something changes on the real backend (the “backend-backend”…)

This is a sound way of putting these things together IMHO, and since the backend for my iPhone app will mostly function as a mediator/proxy it was kind of an obvious opportunity to get to play a little bit with node.js as well ūüėČ (because JavaScript is fun, and because of its asynchronous nature)

But – alas – when I Git-deployed my Azure web site, I got the following message in the Azure portal:

Skærmbillede 2014-04-22 kl. 20.35.36

and clicking the log revealed that Azure was kind of confused by the fact that my repository did not contain an obvious single candidate for something to build & deploy – it had multiple (the Xamarin solution Client.sln and my initial Web API-based dummy server solution Server.sln):

Skærmbillede 2014-04-22 kl. 20.35.46

When a Git-deployed Azure web site has multiple things that can potentially be built & deployed, you’ll usually create a Project app setting and point it to the web project that you want to host in that particular web site, e.g. setting it to src\Something.Web\Something.Web.csproj if that is a web site.

That’s also what we need to do here! – just by pointing to the directory where your node app’s package.json resides – in this case it’s src\Server2 (which was the most awesomest name I could come up with for my server no. 2….) It’s that simple ūüėČ