Running Mac OS X 10.8 'Mountain Lion' in VMware ESXi 5

July 30, 2012 at 7:27 PMPhonicUK

Recently I bought a Mac Mini to use as a ESXi rig to host Mac VMs for development purposes.

Getting Lion running in ESXi 5 is a marginally annoying but entirely doable task. However if you try to follow the same steps with Mountain Lion, you'll very quickly get stuck at a "Waiting for root device..." message and find you're going nowhere.

Thankfully it's actually a pretty simple (if inconvenient thing) to work around:

  • Install OS X 10.7 (Lion) in a VM
  • Upgrade 10.7 to 10.8 after it's up and running
  • Done
That's it. Upgrading works, clean install doesn't.
 
Point of note: During the Mountain Lion installation, the screen may go black/white with a small box in it. If this happens just press any key on the keyboard to wake it up again. It's not dead.

Posted in: Servers | VMware

Tags: , , ,

Mono - Checking if your application is bundled with mkbundle or similar.

April 4, 2012 at 10:40 PMPhonicUK

'mkbundle' is a utility that ships with Mono that allows you to embed the Mono runtime into your application so you are left with just a single executable file that doesn't require Mono to be installed on the target system. You can either embed just certain parts of Mono or the entire thing.

There are cases where you may want to know at runtime whether you are running as part of a bundle or not, thankfully this is extremely simple:

IsBundled = (typeof(int).Assembly.Location == "mscorlib.dll");

When the application is not bundled, the assembly location for the standard objects will be something like /usr/lib/mono/2.0/mscorlib.dll - but when it is bundled then it's just mscorlib.dll since that file is embedded in the current executable.

Posted in: C# Development | Linux | Mono Development

Tags: , , , ,

Binding outgoing .Net web service calls to a specific IP

March 13, 2012 at 5:51 PMPhonicUK

If you're accessing a remote .Net web service where the remote server checks the IP address of the incoming request, either for authentication or some other reason, you can quickly run into some interesting problems on servers with multiple IP addresses, either on different physical interfaces or multiple addresses routed to the same NIC.

So there are some cases where you need to change which of a machines local IP addresses a request will be made from.

While doing this with .Net web services isn't massively complicated, it is tricky finding out any documentation on how to do it.

In this example, I have a remote .Net web service called StatsReporter. I've added the reference and have the generated code. Now I need to extend it:

using System.Net;
using System;

namespace MyProject.StatsReporter
{
    public partial class StatsReporter : System.Web.Services.Protocols.SoapHttpClientProtocol
    {
        protected override System.Net.WebRequest GetWebRequest(Uri uri)
        {
            HttpWebRequest Request = (HttpWebRequest)WebRequest.Create(uri);
            Request.ServicePoint.BindIPEndPointDelegate = BindIPEndPointCallback;
            Request.Proxy = null;
            return (Request);
        }

        public IPEndPoint BindIPEndPointCallback(ServicePoint servicePoint, IPEndPoint remoteEndPoint, int retryCount)
        {
            IPAddress IPEndPoint = IPAddress.Any;

            try
            {
                IPEndPoint = IPAddress.Parse(GetBindIPAddress());
            }
            catch{}

            return new IPEndPoint(IPEndPoint, 0);
        }
    }
}

The original generated code is implemented as a partial class, so the above code can be added to a new file. You'll need to implement GetBindIPAddress() yourself to return the IP that you actually want to use. But aside from that it works.

So what's going on? All you're doing is replacing the WebRequest object that gets created when a service call is made and replacing it with your own. One that has its BindIPEndPointDelegate set to one that will return the IP address to bind to.

In this example I deliberately set the proxy to null to avoid having the service go and 'look' for a proxy server during the first call (which can cause a significant delay) - if your code is going to operate in an environment where non-transparent proxies are being used, you'll want to remove that line.

Posted in: C# Development

Tags: , , , , , , ,