title: How should I access my ApplicationUser properties from ASP.NET Core Views?
body: <p>I'm working on an ASP.Net vNext / MVC6 project. I'm getting to grips with ASP.Net Identity.</p>
  
  <p>The <code>ApplicationUser</code> class is apparently where I'm supposed to add any additional user properties, and this works with Entity Framework and my additional properties get stored in the database as expected.</p>
  
  <p>However, the problem comes when I want to access the details of the currently logged in user from within my views. Specifically, I have a <code>_loginPartial.cshtml</code> in which I want to retrieve and display the user's Gravatar icon, for which I need the email address.</p>
  
  <p>The Razor <code>View</code> base class has a User property, which is a <code>ClaimsPrincipal</code>. How do I go from this <code>User</code> property back to my <code>ApplicationUser</code>, to retrieve my custom properties?</p>
  
  <p>Note that I'm not asking how to find the information; I know how to lookup an <code>ApplicationUser</code> from the <code>User.GetUserId()</code> value. This is more a question about how to approach this problem sensibly. Specifically, I don't want to:</p>
  
  <ul>
  <li>Perform any sort of database lookup from within my views (separation of concerns)</li>
  <li>Have to add logic to every controller to retrieve the current user's details (DRY principle)</li>
  <li>Have to add a User property to every ViewModel.</li>
  </ul>
  
  <p>This seems like a 'cross-cutting concern' that ought to have a centralized standard solution, but I feel like I'm missing a piece of the jigsaw puzzle. What is the best way to get at those custom user properties from within views?</p>
  
  <p>Note: It seems that the MVC team has side-stepped this issue within the project templates by ensuring that the UserName property is always set to the user's email address, neatly avoiding the need for them to perform this lookup to get the user's email address! That seems like a bit of a cheat to me and in my solution the user's login name may or may not be their email address, so I can't rely on that trick (and I suspect there will be other properties I need to access later).</p>