If you're getting a stock 500 error when attempting to run a legacy .NET application on a Windows Server 2012 instance on IIS 8.5, make sure your application pool ID is set up properly.
On IIS 8.5, the Application Pool Id is normally set to ApplicationPoolIdentity instead of NetworkService - here is how to change it:
Also, make sure that your Application Pool is referencing the .NET 2 framework and not the .NET 4 framework.
Pretty simple really - you're not calling the correct method to render your partial views.
You need to use:
@await Html.PartialAsync("MyPartial", Model);
When scaffolding Controllers and Views (for say, a simple CMS Admin functionality for a given Object), you may find that your Select dropdowns are not populated with any SelectListItems (in the form of <option> tags).
This is because there is a bug in the Visual Studio 2015 scaffolder which, while correctly implemented in the Create view, is not in the Edit view.
You will end up with:
<select asp-for="PropertyId" asp-items="ViewBag.MyItems" />
But what you need is:
<select asp-for="PropertyId" asp-items="ViewBag.MyItems"></select>
Easy to miss.
I got caught out this weekend with a couple of client websites that use the Geolocation API to get a location for various tasks. The reason? Google Chrome no longer allows it to work unless the domain uses HTTPS.
Starting in Chrome Version 50, non-HTTPS Geolocation API access has been disabled.
Ordinarily I'd have no problem with this because I can see where the Chrome team are coming from - location privacy is an important thing, but I feel like they've gone about it completely the wrong way.
Firstly, there's barely been any announcement by Google apart from on a few developer blog posts (hence why sites like Hulu.com, Yelp.com etc have been caught out along with small-fry such as myself).
Secondly though, there's no choice to the user. The API call simply fails and outputs a message to the Debug Console (which no user will ever see), leaving them clicking and thinking that the website is broken. Surely a better solution would be to give them a choice by popping open a message saying "Hey, you're about to give your location away over an insecure connection - are you sure?".
Anyway, that's that - it doesn't work any more so you have a choice - either stop using Geolocation, stop using Chrome, or purchase an SSL certificate for your domain and get ready for some 301 redirect action.
If you use a 301 rewrite rule in IIS to ensure all of your URLs are lowercase (perhaps for SEO purposes), beware that you may end up with broken forms in your application.
Sometimes when I'm building an app in .NET MVC, I end up accidentally using CamelCase in my URLs (because I'm a very bad programmer). I might end up with a form declaration which looks like this:
This is because the Controllers themselves in the MVC project conform to the CamelCase pattern, i.e. ProcessingController ...
If you're using IIS Express or similar when developing locally, you probably won't notice - it's only when you deploy to the Live environment that the poo will start to fly, because that is where the ReWrite rules exist.
The reason there is a problem is because the rewrite rule returns a GET request each time it's called. You may be calling /Processing/MyAction as a POST, but when it gets rewritten by the server, the form will actually attempt to post to /processing/myaction as a GET request. And your app will break.