Get Users and related roles and show on View
partial is meant to be used when the class spans multiple files, not when the class is to be extended. If you want to use virtual there is no need to mark the class as partial unless it really does exist in multiple files (a bad design for the most part anyway, with few good uses). If you want to force the class to be inherited, use abstract instead of partial. 

You can remove the default constructor (and the warning suppression) by using default values:

public class User
{
    [Key]
    public int Id { get; set; }
    public string Name { get; set; }

    [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly")]
    public virtual ICollection&lt;UserToRole&gt; UserToRoles { get; set; } = new HashSet&lt;UserToRole&gt;();
}


It is now functionally the same but has less code to maintain. 

Nullable properties can also be defined shorthand:

public class UserToRole
{
    [Key]
    public int Id { get; set; }
    [ForeignKey("Role")]
    public int? RoleId { get; set; }
    [ForeignKey("User")]
    public int? UserId { get; set; }

    public virtual Role Role { get; set; }
    public virtual User User { get; set; }
}


The int? is effectively the same as Nullable&lt;int&gt;, it is a little easier on the eyes without having to mentally parse generics. 

The last comment is about your repo method. It could be shortened up a little bit:

public List&lt;UserViewModel&gt; GetUsers()
{
    return db.Users
        .Include(u =&gt; u.UserToRoles.Select(ur =&gt; ur.Role))
        .Select(u =&gt; new UserViewModel
        {
            UserName = u.Name,
            Roles = u.UserToRoles.Select(ur =&gt; ur.Role.Name)
        })
        .ToList();
}


Or, if you really want to shorten it up:

public List&lt;UserViewModel&gt; GetUsers() =&gt; db.Users
                                           .Include(u =&gt; u.UserToRoles.Select(ur =&gt; ur.Role))
                                           .Select(u =&gt; new UserViewModel
                                           {
                                               UserName = u.Name,
                                               Roles = u.UserToRoles.Select(ur =&gt; ur.Role.Name)
                                           }).ToList();


The only reason I would use the intermediate users variable in the method is to do debugging inside the method. You could add a breakpoint on the return users; line and debug the value. If you are confident in the operation of the query and the results, shortening it up helps with code maintenance.