Don’t forget to remove the end forward slash when enabling CORS

You ever run into an issue with your code, spend way to long looking at it and not get anywhere?  Especially one that you’ve solved before but having a lapse in memory.  That was me all too recently.  I was setting up an app that consisted of three projects in a solution.  One project for the API, one for the DTO, and another for the MVC.  The problem with this setup is that any Javascript call from the MVC project to the API will be blocked when the data comes back due to the browser enforcing same-origin policy.  Microsoft has a great write-up on how to Enable CORS within an ASP.NET Web API 2 project.  For your own sanity please make sure you go the whole through section.  I mean, the whole thing, all the way to the end, because at the end of the section is a rather important fact.  When you are defining the EnableCors attribute on the API controller you need to make sure that the forward slash at the end of the origins parameter is removed.

Good: [EnableCors(origins: "http://localhost:49332", headers:"*", methods:"*")]

Bad: [EnableCors(origins: "http://localhost:49332/", headers:"*", methods:"*")]

That is it.  That single forward slash tripped me up.  The error written to the web DevTools console was
Access to XMLHttpRequest at 'http://localhost:49342/api/users/name/smith/' from origin 'http://localhost:49332' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Hope this helps you waste a little less time.

Generating Entity Framework classes for Database First project

Not all projects, or development teams, use Code First with Entity Framework for building and maintaining their database.  There are plenty of reasons for doing it either way but that discussion is outside of the scope of this post.  What this post is going to focus on is generating your EF classes in a Database First environment.

Microsoft has plenty of great documentation for developers and one such post that I used recently was Getting Started with EF Core on ASP.NET Core with an Existing Database.  My setup is Visual Studio 2017 Community Edition and a .NET Core 2.1 project structure.  The database is running on a free, local instance of SQL Server 2017 and consists of a handful of tables.  To generate the classes I utilized the Package Manager Console (PMC) in Visual Studio and the Scaffold-DbContext command.

Scaffold-DbContext "Data Source=localhost\SQLEXPRESS;Initial Catalog=MyDatabase;Integrated Security=True;" Microsoft.EntityFrameworkCore.SqlServer -outputDir Repository -Verbose

The connection string is pretty basic.  I’m telling it to connect to a database on my machine called MyDatabase and use my Windows Credentials for authentication.  The files generated should go into the directory called Repository in my project.  And for help with debugging any problems I include the -Verbose parameter.

Upon completion all generated files were open in my VS instance for inspection and located in the folder I set as the output destination.  If this didn’t happend and you have an error message make sure that your project builds on its own.  If the project doesn’t build then the Scaffold-DbContext won’t be able to generate the files.  One thing to check before you submit your code to any repository is that in your Context.cs class the connection string used for Scaffold-DbContext is hard-coded into the file.  If the code is going to a public repository you’ll want to make sure this line is removed.