Linq To Sql - MVC2 - Set ViewModel Values With Retrieved From Db Object's Values With DataAnnotations

Prior to using a ViewModel, I could easily pass the "soon to be edited" object directly to the view without needing to fuss over setting individual properties etc as the View conveniently accepted the Employee type directly..

[HttpGet]
public ActionResult EditEmployee(int? id)
{
EmployeeRepository ER = new EmployeeRepository();
Employee SomeEmployee = ER.GetEmployee(id.Value);
if(SomeEmployee!=null)
return View(SomeEmployee);

But now I'm using a ViewModel with DataAnnotations attributes applied over the top of various properties for validation purposes. Which creates a problem.. After fetching the "soon to be edited" object from the db, setting the ViewModel's values is suddenly a whole lot more complicated. I can't simply pass the retrieved object straight to the view, as the View now expects the VMEmployee type instead. I would like to be able to do something like:

[HttpGet]
public ActionResult EditEmployee(int? id)
{
EmployeeRepository ER = new EmployeeRepository();
Employee SomeEmployee = ER.GetEmployee(id.Value);
if(SomeEmployee!=null)
return View(new VMEmployee(SomeEmployee));

All paths seem to lead to a huge constructor which manually sets the values of each individual property. But I never had to do that before when I wasn't using a ViewModel. Model binding was a blessing! My objects also have complex child objects, which my form is also collecting values for, so this would be a huge/verbose task against DRY principals. I don't even really want to use a ViewModel, but am forced to because I need two different DataAnnotations rule sets for different validation scenarios applied to the same object.

All I want to do is be able to have two different DataAnnotations rule sets for different scenarios. I.e. public-facing www site vs internal-facing admin site. DataAnnotations doesn't seem to be flexible enough to easily cater for this common need. I've tried AutoMapper, but it throws an error saying it can't map my object types, I suspect because Employee was auto-generated by LINQ to SQL. What is the most elegant way to achieve this while sticking to DRY principals?