Rowan says: "It's really up to you. There are two main reasons you may want to introduce a repository which are not handled by DbContext:
* Removing any strong coupling between your app logic and data access layer. Though in reality, even with this abstraction it is very difficult to swap out a data access layer unless you build and test for multiple data access technologies right from the start.
* Constraining the operations that the app layer can perform on the database. DbContext exposes IQueryable so the app can compose any query allowed by LINQ. Repositories that don't return IQueryable can help you control what is sent to the database.
Ultimately it comes down to a philosophical/style/preference decision. Many apps have been built successfully using either approach."
@andriysavin: I've done it with separate projects in a real-world application. The location of the models are identified by their namespace (which can be in a referenced assembly from another project) and the migrations can live away from the web project.
In Solution Explorer, the default startup project would typically be your web project. In the Package Manager console, you can define a different default project to run migration commands in.
I edited the placeholder images that were already created during the export process, so that I didn't have to worry about the dimensions. To see a full list of possible tile dimensions, scroll to the "Asset size tables" section in the documentation, at the bottom of this page here: https://msdn.microsoft.com/en-us/library/windows/apps/mt412102.aspx
The manifest file can be viewed in a visual mode or in code mode. You may have to right-click to view the code version, and fix any potential issues with it. Then try to double-click it again to view in the visual mode.
There's nothing wrong with either. Many of our customers use Azure on Windows or MacOS across various browsers, including Chrome.
I have multiple MS accounts. This particular machine has a MS account attached to it for Store downloads that I usually use to auto-login on Edge and IE, both of which I use during ASP.NET web dev, MSDN, etc.
I use a different MS account for my internal Azure account, which I usually use in Chrome for some demos.
Use what works best for you. The Azure portal works on any modern browser on any platform. It also allows you to build Mobile App Services and Notifications for iOS and Android in addition to Windows. You can write web apps in .NET or any other web framework/language and deploy to Windows or Linux.
The cross-platform and cross-browser support is intentional. :)