Error Adding View in Entity Framework June CTP: CS0104 ColumnAttribute is an Ambiguous Reference

by Tarah on 11. August 2011 14:33

Recently I upgraded to the Entity Framework June 2011 CTP to be able to use Enums in my project model.  All went well.  Until I needed to add a strongly typed view that wasn’t empty.  When trying to create the view I received two errors:

  • CS0104 - Compiling transformation: 'ColumnAttribute' is an ambiguous reference between 'System.ComponentModel.DataAnnotations.ColumnAttribute' and  System.Data.Linq.Mapping.ColumnAttribute’
  • CS1061 – Compiling transformation:  'System.ComponentModel.DataAnnotations.ColumnAttribute' does not contain a definition for 'IsPrimaryKey' and no extension method 'IsPrimaryKey' accepting a first argument of type 'System.ComponentModel.DataAnnotations.ColumnAttribute' could be found…

 The first error occurs because ColumnAttribute is in both System.ComponentModel.DataAnnotations and System.Data.Linq.Mapping.  It is unclear (ambiguous) as to which should be used.  I believe that the second error results from the an attempt to use System.ComponentModel.DataAnnotations to create the view which does not contain a definition for IsPrimaryKey.  So somehow we need to get Visual Studio to use System.Data.Linq.Mapping instead.  After a bit of Googling the following solution presented itself:

Navigate to C:\<Visual Studio Install Path>\Common7\IDE\ItemTemplates\CSharp\Web\MVC 3\CodeTemplates\AddView\CSHTML

Here you will see all the .tt files for Create, Delete, Details, Edit,Empty and List.

You will need to edit all of these files except for Empty.tt

Find the line:

var column = attribute as ColumnAttribute;

Change it to:

var column = attribute as System.Data.Linq.Mapping.ColumnAttribute;

Save and restart Visual Studio.  Try and add a view!


Keep website registrations / signups simple

by Phil on 12. May 2011 13:55

One thing that continually pains me on my daily travels around the web is the seemingly relentless requirement to sign up and register to use most websites.

Requiring registration in itself is not necessarily without reason (or merit) – web sites are in a very competitive space these days, and have to strive to provide compelling offerings to their visitors to keep them coming back. But the amount of information they expect a visitor to provide as part of registration is often cumbersome if not daunting.

Large forms absolutely do put people off completing registration on your website. Here are some key considerations to think about when designing your online sign-up or registration processes.

1. Do you really need to know that?

Think carefully about what information you are asking visitors to give you. People are very protective of their personal details. And fields such as Date of Birth, Address, Post code, Phone number, etc. start raising red flags immediately. Unless you have a very good reason for needing to know personal details (an online store needing delivery address for example) don’t ask for that information.

2. Do you need to know that right now?

Consider keeping the information required to sign up as bare minimum as possible – perhaps its just an e-mail address and a password. Then as the registered user starts to use a feature of your website that requires more information, ask for it then. People are far more likely to give up additional small pieces of information on demand if they are already a registered user and therefore have a vested interest.

An example might be a registered user making his first post in your online forums; “Hey there, we notice we don’t have a nickname on file for you yet – would you like to give us one now so you can complete your post?”

3. Provide an incentive to give more information

An approach I’ve seen several sites using is to provide a virtual incentive to providing more information over time. For example LinkedIn will let you know that ‘your profile is 87% complete’ because they have more fields which can be filled with your information. While arguably this is a pretty arbitrary measurement, it is an incentive to fill in that information. It’s surprising how much it motivates people to have a goal (in this case ‘100%’) to reach.

4. Keep private information private!

Accepting personal information about a visitor on your website comes with a moral (if not legal) requirement to look after that information in a responsible manner. Facebook controversy has shown how sensitive people have become to their details being published without their explicit knowledge.

Be absolutely transparent with explanations of why you need to know personal information and what you will do with it. If, for example you have a profile for each user of your website; be clear about what will be shown publicly/what will be shown to other members, and give options to enable/disable showing such information to the user.


These principles can be applied to most online forms, not just registration or sign ups. Filling in forms is no one’s idea of fun. So you, as a responsible site owner should try to identify the pain points in your forms, and make it as simple as possible for someone filling them in.


Don't publish your error messages!

by Phil on 2. May 2011 22:26

While browsing the website of a certain ‘big name brand’ website this morning I came across this:


Ironically the key thing to consider here is written in plain text just below the heading: “The following information is meant for the website developer for debugging purposes.”. For internal error messages like these – that even include a stack trace from the application, to end up being public facing is a pretty big deal. Apart from being an extremely poor experience for the end user - it is a serious security risk.

The error message and accompanying stack trace from the application unnecessarily exposes lots of internal information about the server and the website running on it to the outside world. This kind of information can easily help form the building blocks of a security breach for someone who knows what to look for.

Some advice for developers:

  • Debug mode should always be turned off before deployment to your live production environment. For ASP.NET developers like myself this means Don’t run production ASP.NET Applications with debug=”true” enabled.
  • Any stack traces or internal errors produced by your application should always be hidden away from end users and logged/audited internally only. For ASP.NET consider using a framework such as ELMAH for error logging.
  • It’s often overlooked, but when the worst does happen and an error is encountered - try to show your end users something which will actually be a useful explanation for them, rather than something they’ll just find confusing. For ASP.NET this means using custom errors.