Silverlight 3 and Binary Bindings

One of the tasks on my todo list has been to switch our Silverlight project at work from basicHttpBindings in WCF to the new Binary Binding – which should hopefully reduce network traffic, improve security etc etc.

I was kind of dreading this task, expecting it to be truly awkward, but in actual fact it was a piece of cake.

Two major steps:

1. Update the web.config file for the service, replacing the binding details with the new structure detailing the binary binding, and changing the endpoint. For example:

The original binding had:

    <binding name="Application.Binding">
        <security mode="Transport">
            <transport clientCredentialType="None" proxyCredentialType="None" realm="" />

With the endpoint defined:

<endpoint address="" binding="basicHttpBinding" contract="Application.IApplication" bindingConfiguration="Application.Binding">
        <dns value="localhost"/>

To switch this to binary binding, simply add:

    <binding name="Application.BinaryBinding">
        <binaryMessageEncoding />
        <httpsTransport />

And use this new binding as follows

<endpoint address="" binding="customBinding" contract="Application.IApplication" bindingConfiguration="Application.BinaryBinding">

Note that both of these binding definitions are running on SSL; if you wanted to run the binary binding on http, simply drop the “s” from the line <httpsTransport />.

2. Refresh the service references in Visual Studio.

Thats it!

Bug Hunt - TFS 2010, Build Server

After deploying TFS 2010, I hit a strange bug with the build server portion of the system – I was getting errors saying that it was unable to locate some build configuration files on the TFS server itself – and these were actually files that were distributed with TFS .

Curious I thought.

Then I noticed the paths that the server was looking in: C:\Program Files\MSBuild\Microsoft   for Silverlight and Visual Studio (we run both types of builds here).

Then the penny dropped. This was a 64-bit server, and a quick login confirm my suspicion – the installers had placed them into C:\Program Files (x86) and NOT C:\Program Files. A quick copy later and everything was up and running.

Annoying bug, but that’s the way it goes when beta testing stuff!

Social Networking and Privacy - where do we draw the line?

I’m sure pretty much everyone reading this has at least heard of one of the many social networking websites that have sprung into existence over the last few years – from the big names (Facebook), the smaller (MySpace) and perhaps the even smaller (Bebo). The micro blogging phenomena that is Twitter is only agitating the explosion of networking, and not only with people you know.

After speaking to one of my colleagues today regarding my rather impressive Google positioning (I seem to occupy the whole first page of results when you search for my name – including various contact numbers, email addresses and such), I got thinking about the amount of information that a general person seems to throw into the pot that is the internet. Not only is this a concern, but it further worries me considering my last post on personal information security where a friend of mine was phished for their MSN details.

So what does it mean? These days we seem to be happy to put, what is effectively, sensitive information into a website – such as our full name, contact numbers, e-mail addresses, date of birth and even partial addresses. Further we provide information on hobbies (typically a good indication to passwords or security questions), pets, family, and the such.

Granted, applications such as Facebook attempt to provide a modicum of security – by restricting access to this information by letting you select your friends – however, it seems a lot of people just add friends regardless of how well they know them – or even if they know them at all! It seems we are potentially exposing a rather significant amount of information about ourselves without actually stopping to consider the consequences.

And this is the age that people are most concerned about their personal information falling into rogue hands? I don’t think so.

What do we need to do? Apart from the obvious – stop and think about what we are doing when we plug all our information into a website, and consider if we actually trust the people that we are dealing with (both personally and commercially) online before we grant them access – but also some means of validating that we are who we say we are. By a form of electronic identity validation, we can effectively eradicate the problems of information exposure – if you can prove who you are, are there any problems associated with your information falling into rogue hands?

Obviously this sort of solution does not solve the problems that occur from minors providing significant amounts of information on these social networking mediums, however, that in my eyes is a totally different issue – and something that requires a significant amount of education to those concerned that the information they provide on the internet and via instant messaging is in no way secure and guaranteed as such – and perhaps additional restrictions within applications themselves on the amount of information that minors can enter – for example, why would a minor want to provide their contact telephone numbers on Facebook? Surely anyone they actually want to contact them (i.e. their location friends) would actually already know this, or have other ways of making contact?

Food for thought …

Visual Studio 2010, Silverlight 3 and a Cryptic Error

For the last few days I’ve been fighting a strange error while porting an application to Silverlight 3 …

Obviously, I had to use Visual Studio 2010 for the work – why not, I’m trying one beta technology, might as well make life interesting eh?
Actually, there are technical reasons why you would want to use VS 2010 for the SL3 development, but I’m not going to discuss them here at this point in time – they have been beaten to death elsewhere on the net.

Anyway, I hit this error message:

Error   3        The "ValidateXaml" task failed unexpectedly.

System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Development\{Project}\{Assembly}.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

File name: 'file:///C:\Development\{Project}\{Assembly}.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.  This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous.  If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See for more information.

Note that I have hidden the project name and assembly name, as it’s for something that I don’t want to expose yet!

The path is not a network path, its local, and it’s a trusted location. I have full admin rights on the machine, so I knew it wasn’t permissions related, but I checked that too just in case.

I was stumped.

Then something hit me this morning. I wonder if it’s a flag on the assemblies themselves. These particular assemblies are 3rd party libraries, and everything we had developed internally was working fine, so I went digging.

Turns out that they had the “block” flag set – this is set by Windows for files that are downloaded from the internet, and apply a restrict set of permissions in some applications such as Internet Explorer, Explorer, HTML Help viewer etc. And it seems Visual Studio / .NET 4.0 beta compiler.

It would be far more useful if the error text actually mentioned it.