Roberto Bonini

"Developers, by definition, are engineers lost in the details of implementation"

Quote of the Day - @SlexAxton

A Microsoft engineer could say "I like meat" and somebody would blog about how Microsoft just declared war on Buddhism

-Alex Sexton on Paul Thurrots blog post The Last Version of Windows?

»

Great Scott !!

alt

(via CommitStrip)

For the record, I don't torrent......

»

Windows Server 2012 Essentials - "Restore Files Wizard Has Stopped Working"

Isn't annoying when you really REALLY neeed to restore one critical file and you run into a brick wall?

Fear not! The suggested remedy is to uninstall KB3023562 from all client PCs.

And it worked for me as well :)

»

I want Tea

Funny (and true):

alt

»

Update for Windows Azure Backup for Windows Server Essentials 2012

I've been running Windows Home Server since its second beta - away back in 2007. Man, how the time flies!

Last year I moved over to Windows Server 2012 Essentials running on a nice new Dell box with some oopmh.

In October I decided to enable Windows Azure Backup as an experiment - mainly to see the price. I was never going to be able to afford all 5Tb of data being in the cloub, so I started with just 300Gb.

It seems to be about £45 a month, tho its been both more and less.

Starting April 1st ( no joke) the pricing structure has been changed. It should now be cheaper to store the same amount of data. Based on the Windows Azure Pricing Calculator my bill should be cut in half, almost.

However - there is a catch - you have to update the Microsoft Azure Recovery Agent to take full advantage of the lower prices.

When I ran the update, I got this:

The Microsoft Azure Recovery Services Agent installation has failed.

Error : Failed to install Microsoft Azure Recovery Services Agent.

Problem : 1603:Fatal error during installation

The accepted solution seems to be to uninstall Microsoft Azure Recovery Services Agent and then re-install.

But, if you're using the Add-In, it gets a bit more complicated than that.

So....

Make sure that you have the Backup Vault certificate from Azure dashboard, and the Certificate that was originally generated when you first installed the agent. And make sure that you remember your 16 charecter pass phrase. Aditionally, go to the Azure dashboard and make sure you allow your server to re-register,

  1. Remove the Addin using the dashboard - make sure the box to remove the agent is also ticked.
  2. Reboot
  3. Re install the Addin using the dashboard. This will also reinstall the old agent, but will leave your server unregistered.
  4. Install the updated agent and follow the instructions in the wizard.
  5. Check in the Dashboard that it is recieving infomation from the new Agent

And you should be done. The new agent will magically remember the previous configuration of your protected files, retention policy and so on.

»

I would love this!

From XKCD

Shoot, it landed in the golf course. Gonna be hard to get it down the--oh, never mind, it rolled onto the ice hazard. Face-off! "Shoot, it landed in the golf course. Gonna be hard to get it down the--oh, never mind, it rolled onto the ice hazard. Face-off!"

»

From The Department of Should Have Thought Of This Before

Have You Tried Rebooting? via CommitStrip

»

Cartoon Of The Day

cartoon

»

Entity Framework Tip of the Day

Yesterday, I was doing so some work with EF and ran into something unusual - my navigational properties weren't being populated.

I rechecked my model and the DB schema and eerything was normal.

So it turns out that my entity object had just been inserted earlier in the procedure. This makes sense becuase EF usually does the navigational property population when you pull an entity directly from the DB.

So - either I find a solution or re-write my method to pull down the recently inserted entity again after insertion.

It turns out there is a single line of code that will fix everything:

Entities.Entry(item).Reference(c => c.NavgationProperty).Load();

This forces EF to load the property using the defined FK - and then using that navigational property works as expected. You'll have to do this for each property that needs to be populated.

Hope someone finds this useful.

»

Microsoft Translate API Errors

Like any good dev, I have side projects. And like any good busy dev, I don't get enough time to finish them properly.

So this time of the year is always productive as i try and get stuff done before returning to work.

Today I needed to translate a whole bunch of resource strings into a bunch of other languages. So I thought the Bing Translate Api would be a good fit. So off I went to Azure Marketplace to add the service to my Azure subscription.

And right away I started running into problems - its nowhere to be found.

To cut a long story short - it seems to have been superceded by the Microsoft Translator API.

Now. Signing up and adding it to my existing subscription is simplicity itself.

And when you get to the dashboard for the service, you get something that looks like this:

alt

The proxy class is nice and compact and excellent and saves the hassle of adding a full blown service reference to your VS2013 project.

Then they give you this small code snippit to use the proxy class:

var client = new TranslatorContainer(new Uri("https://api.datamarket.azure.com/Data.ashx/Bing/MicrosoftTranslator/v1/"));
client.Credentials = new NetworkCredential("accountKey", "Insert Account Key");
var marketData = client.Translate(
"hello",
"nl",
null
).Execute();

(obviously you need to swap "Insert Account Key" with your actual account key)

One thing to note here is that this is using V1 of the API - and its just for OData (tho this doesn't preclude you from calling it from javascript). This API is fairly basic. There is a more powerful V2 API floating about that requires a bit more elaborate authentication.

(The difference between the two versions caught me out for a while.)

Now, when I went to use the proxy class right out of the box, I got an entity mismatch error:

"There is a type mismatch between the client and the service. Type 'Microsoft.Translation' is not an entity type, but the type in the response payload represents an entity type. Please ensure that types defined on the client match the data model of the service, or update the service reference on the client."

Now if you open Fiddler and allow HTTP decryption, you'll see that the request actually suceeds. So the error is not in the call, or the authentication (as I initially thought), but in parsing the response.

And if we look at the error text, we see that it spells out eaxtly what the issue is - 'Microsoft.Translation' is not an entity type

Of course, being the doofus that I occasonally am, I missed that completely at first.

Once I noticed that, it hit me - I simply need to tell the DataServiceContext that Microsoft.Translation is an entity type.

And how do you do that?

Enter the [DataServiceEntity] attribute.

So. Open up the proxy class you downloaded from the Azure dashboard page and decorate the Translation, Language and DetectedLanguage classes with [DataServiceEntity] and you're good to go.

Your code should look like this:

[DataServiceEntity]
public partial class Translation {

    private String _Text;

    public String Text {
        get {
            return this._Text;
        }
        set {
            this._Text = value;
        }
    }
}
[DataServiceEntity]
public partial class Language {

    private String _Code;

    public String Code {
        get {
            return this._Code;
        }
        set {
            this._Code = value;
        }
    }
}

[DataServiceEntity]
public partial class DetectedLanguage {

    private String _Code;

    public String Code {
        get {
            return this._Code;
        }
        set {
            this._Code = value;
        }
    }
}

And if anyone knows anyone at Microsoft, hopefully the proxy class file can be updated.

»