Should we use Entity Framework

You shouldn't need SQL Server to put an ASP.NET application online. If your site requires database persistence, then yes, you'll need SQL Server installed, but not necessarily on the same server. If your requirements were that "we need to deploy a website", then there's no indication that SQL Server would be a requirement, and I would not expect them to give you access. Many hosts, such as http://discountasp.net, provide hosting for ASP.NET applications and SQL Server databases completely separately.

One solution that you DO have is to host your ASP.NET application on the server of this company (assuming you're still on speaking terms), and host your SQL Server database on another machine somewhere completely different - they don't have to be on the same machine. Your web.config file will let you change your connection string so you can have them separately.

I don't know the specifics of the conversation, but unless you tell them that you specifically need SQL Server (though most web applications do have a database of some kind and you can pretty well assume it's needed), hosting companies still reserve the right to give/sell SQL Server separately. If you have admin access to your hosting machine, I would suggest just installing SQL Server Express unless you need some of the more serious SQL features. Most of the time the reason hosts sell SQL Server databases/install separately is the EXTREMELY hefty license price tag of the the non-express version.

I hope this helps, and leave a comment if I need to go into more detail in a particular area.

I don't see any reason for the Repository pattern to not work with Entity Framework. Repository pattern is an abstraction layer you put on your data access layer. Your data access layer can be anything from pure ADO.NET stored procedures to Entity Framework or an XML file.

In large systems, where you have data coming from different sources (database/XML/web service), it is good to have an abstraction layer. The Repository pattern works well in this scenario. I do not believe that Entity Framework is enough abstraction to hide what goes on behind the scenes.

I have used the Repository pattern with Entity Framework as my data access layer method and am yet to face a problem.

Another advantage of abstracting the DbContext with a Repository is unit-testability. You can have your IRepository interface to which has 2 implementations, one (the real Repository) which uses DbContext to talk to the database and the second, FakeRepository which can return in-memory objects/mocked data. This makes your IRepository unit-testable, thus other parts of code which uses IRepository.

public interface IRepository
{
  IEnumerable<CustomerDto> GetCustomers();
}
public EFRepository : IRepository
{
  private YourDbContext db;
  private EFRepository()
  {
    db = new YourDbContext();
  }
  public IEnumerable<CustomerDto> GetCustomers()
  {
    return db.Customers.Select(f=>new CustomerDto { Id=f.Id, Name =f.Name}).ToList();
  }
}
public MockRepository : IRepository
{
  public IEnumerable<CustomerDto> GetCustomers()
  {
    // to do : return a mock list of Customers
    // Or you may even use a mocking framework like Moq
  }
}

Now using DI, you get the implementation

public class SomeService
{
  IRepository repo;
  public SomeService(IRepository repo)
  {
     this.repo = repo;
  }  
  public void SomeMethod()
  {
    //use this.repo as needed
  }    
}