Using FluentValidation for ASP.NET Web API

If you want to implement validation for your ASP.NET MVC Web Application, this is easily done in a number of ways using ASP.NET MVC's own validation mechanisms as well as using NuGet packages such as FluentValidation for ASP.NET MVC: https://github.com/JeremySkinner/FluentValidation

Unfortunately, even though there is also a FluentValidation NuGet package for ASP.NET Web API (https://www.nuget.org/packages/FluentValidation.WebAPI/), there is no corresponding documentation for ASP.NET Web API on the FluentValidation Wiki!(https://github.com/JeremySkinner/FluentValidation/wiki)

Thankfully, though, there are a few articles which address just how to accomplish this using the FluentValidation library for ASP.NET Web API!

http://www.justinsaraceno.com/2014/07/fluentvalidation-with-webapi2/

https://www.exceptionnotfound.net/custom-validation-in-asp-net-web-api-with-fluentvalidation/

Expand or Collapse Regions in Visual Studio 2015

I frequently work with regions throughout my C# code, so I usually need to expand or collapse all regions in my code especially when I am refactoring code.

Therefore, I wanted to see if there was an easy way to accomplish this within Visual Studio.

Well, by default, Visual Studio uses the Edit-->Outlining menu to control the expanding and collapsing of regions:

However, there are some Quick Launch commands also available to you specifically while working with Regions!

These Quick Launch commands come to you courtesy of the Productivity Power Tools 2015: https://visualstudiogallery.msdn.microsoft.com/34ebc6a2-2777-421d-8914-e29c1dfa7f5d

Installing this extension adds Quick Launch items for "CollapseRegions" and "ExpandRegions":

In case you are not already aware, the Quick Launch menu appears in the top right hand corner of Visual Studio and allows you to search for various commands available to Visual Studio:

Understanding Attribute-based routing in ASP.NET Web API

If you are new to Web API, you may not completely understand how Attribute-based routing in ASP.NET Web API works.

The documentation for ASP.NET Web API Attribute-based routing is rather sparse and very confusing at times.

Therefore, I thought I would provide some clarifications on Attribute-based routing for anyone who is developing with ASP.NET Web API:

1. Attribute-based routing, by default, takes precedence over any routing rules defined in WebApiConfig.cs
2. When defining your Attribute-based routes, there is no way to enforce having all of your routes defined in lowercase or camel-case, therefore, it is best to simply standardize the route name casing your will be using and ensure that the entire development team is aware of this standard and follows it throughout all your development.  A good way to publish these standards is through a ReadMe.md file in source control or publishing it on an Intranet Wiki site.
3. Once you define a [RoutePrefix] attribute at the top of your Web  API Controller class, you MUST define Attribute routes for all of the other methods in your Web API Controller.
4. For default named methods such as Get, Put, Post and Delete, you will still have to define the default attribute route of [Route("")]
5. Even when using convention-based naming, it is best to decorate your Web API method names with their appropriate action types such as [HttpGet], [HttpPut], [HttpPost] and [HttpDelete]
6. For methods such as Get and Delete, you usually DO define route parameters.  Therefore, a GetById or a Delete method, might have the following Route attribute defined: [Route("{id}")]
7. For methods such as Post and Put, you usually DO NOT define any route parameters.  This is because the assumption is that you are posting a model using the [FromBody] attribute, so a Post or Put operation assumes that you are not sending values in the Url.
8. Any parameters which are not explicitly defined in the route will automatically end up with query-string based routes rather than RESTful routes.  Therefore, it is best to define ALL parameters in your attribute based routes.  Ex: [Route("{id}/details/{detailsid}")]
9. Parameter names DO make a difference in Web API!  Therefore, if your parameter is named myId, then you need to define a route as follows: [Route("{myId}")].  If you define a route as follows: [Route("{id}")] this will NOT work!
10. You CAN have the same [RoutePrefix] on multiple Web API Controllers!  Therefore, if you want to split up your functionality across multiple Web API Controllers, you can readily do so and just adjust your route attributes accordingly on each of your Web API methods.
11. If you have inheritance hierarchies in your Web API controllers, you need to standardize the conventions for your Attribute-based routes such as all Details for a particular class be accessed using a Route such as the following: [Route("{id}/details")]
12. When performing Get requests which receive a collection of all the items, the standard is to simply have an empty route: [Route("")].  However, if you want to retrieve a specific item, then you should parameterize the route: [Route("{id}")].  These can be distinguished by having method names such as Get and GetById.  
13. If you install Web API Help or Swagger for your ASP.NET Web API project, you can review all of your routes to make sure they are correct in an easy to view web page, by either navigating from your web browser to either /help or /swagger in the root of your Web API project.  Therefore, you might have a Url such as http://localhost/MyWebAPI/help or http://localhost/MyWebAPI/swagger

That should be pretty much all you need to get started developing your ASP.NET Web API Web Applications using Attribute-based routing!

Windows Server 2016 RTM Released!

In case you haven't already heard the news, Windows Server 2016 was released!

Even though you cannot yet download it from MSDN, you can download a 180-day evaluation version from here and try it out for yourself: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2016

Oracle Database Connection String for ODP.NET using TNSNames.ora

If you are using the TNSNames.ora file for connecting to your Oracle database, you might be a bit confused about using the following Oracle connection string as listed here: https://www.connectionstrings.com/oracle/


Normally, when you see something like that, you think immediately of setting up a DSN in ODBC Data Sources, right? Well, in this case, you do not need to set up anything in ODBC Data Sources! You simply configure your Net Service Name in your Oracle Client so that you have one or more entries in your tnsnames.ora file as follows:

Now, the Data Source attribute in your Oracle connection string simply corresponds to one of the entries in your tnsnames.ora file (in this case, there are entries for ORCL11G and ORCL respectively).

That is all there is to understanding how to build your Oracle database connection strings using TNS Names!

Oracle Database Connection String for ODP.NET without TNSNames.ora file

I was recently attempting to follow the Oracle database connection string listed on https://www.connectionstrings.com/oracle/ using the ODP.NET Data Provider in order to establish a database connection to my Oracle 11g server, but I was soon faced with this error message:

ORA-12514: TNS: listener does not currently know of service requested in connect descriptor

I couldn't figure out the cause of this problem, since this same connection information is listed in the Oracle documentation (under the section for "Specifying the Data Source Attribute")!  https://docs.oracle.com/html/E10927_01/featConnecting.htm

Fortunately, one of my co-workers suggested using the following alternative connection string by replacing SERVICE_NAME with SID:


Making this simple change resolved my connectivity issues!

Using ASP.NET MVC Futures to eliminate Magic Strings

If you have used RedirectToAction throughout your ASP.NET MVC Controllers, you have probably experienced the frustration of having to manually type in string names of controllers as follows:


However, with ASP.NET MVC Futures, you can eliminate typing in these "Magic Strings" for these Redirects and instead rely on strong typing and using lambda expressions!

In order to get started, you first have to install Microsoft.AspNet.Mvc.Futures as a NuGet package:

Once you have installed this NuGet package, you will end up with a reference to "Microsoft.Web.Mvc".  You will have to add a using statement for this library to the top of your MVC Controller file.

Once you have done that, you can easily replace this RedirectToAction functionality in your Controller methods as follows:



That is all there is to cleaning up numerous "Magic Strings" from your ASP.NET MVC Web Application!