Entity Framework: table without primary key

If I want to use them and modify data, must I necessarily add a PK to those tables, or is there a workaround so that I don't have to?

For those reaching this question and are using Entity Framework Core, you no longer need to necessarily add a PK to thoses tables or doing any workaround. Since EF Core 2.1 we have a new feature Query Types

Query types must be used for:

• Serving as the return type for ad hoc FromSql() queries.
• Mapping to database views.
• Mapping to tables that do not have a primary key defined.
• Mapping to queries defined in the model.

So in your DbContext just add the following property of type DbQuery<T> instead of DbSet<T> like below. Assuming your table name is MyTable:

public DbQuery<MyTable> MyTables { get; set; }

In EF Core 5.0, you will be able to define it at entity level also.

[Keyless]
public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public int Zip { get; set; }
}

Reference: https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/whatsnew#use-a-c-attribute-to-indicate-that-an-entity-has-no-key

Update to @CodeNotFound's answer.

In EF Core 3.0 DbQuery<T> has been deprecated, instead you should use Keyless entity types which supposedly does the same thing. These are configured with the ModelBuilder HasNoKey() method. In your DbContext class, do this

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<YourEntityType>(eb =>
        {
            eb.HasNoKey();
        });

}

There are restrictions though, notably:

• Are never tracked for changes in the DbContext and therefore are never inserted, updated or deleted on the database.
• Only support a subset of navigation mapping capabilities, specifically:
  • They may never act as the principal end of a relationship.
  • They may not have navigations to owned entities
  • They can only contain reference navigation properties pointing to regular entities.
  • Entities cannot contain navigation properties to keyless entity types.

This means that for the question of

If I want to use them and modify data, must I necessarily add a PK to those tables, or is there a workaround so that I don't have to?

You cannot modify data this way - however you can read. One could envision using another way (e.g. ADO.NET, Dapper) to modify data though - this could be a solution in cases where you rarely need to do non-read operations and still would like to stick with EF Core for your majority cases.

Also, if you truly need/want to work with heap(keyless) tables - consider ditching EF and use another way to talk to your database.

I learned my lesson by working around it. The short answer is DO NOT work around it.

I used EF6 to read a table without a PK but having a compound key. Multiple rows with the same compound key would have the exactly same record. Essentially only one row has been read but used to fill all rows. Since there were million records and it only occurred for a relatively small amount of records which made it very difficult to find the issue.

We have a table without a unique ID column. Other columns were expected to create a composite key, but over time the data has sometimes not had values in all composite key columns.

Here is a solution using the .NET Entity Framework:

[Key]
[Column(Order = 1)]
public Guid FakeId { get; set; }
public ... other columns

And change the SQL to select this:

SELECT NEWID() as FakeId, ... other columns