.NET Core and C# Developers Throughout 2019

Hesam Seyed Mousavi, May 30, 2019

This article is for .NET developers who would like to start programming with .NET Core. Here, I have analyzed and compared the main differences between these two technologies, speaking as a .NET developer.

Hesam Seyed Mousavi DOT NET CORE

Source: prproject

blog.mousavi.fr

Remembering the first time I developed in .NET Core, it was a huge adventure; oh my goodness! It had a JSON configuration file, like NodeJS’s packages.json and was hard to understand and configure. Looked like the Xamarin installation on a Windows machine, a real pain.

I gave up on that .NET Core thing and continued programming in .NET Framework until new .NET Core versions were launched, and it became an excellent framework as we expected.

What are we going to do?

We are going to create a new MVC ASP.Net Core project named FSL.NetCoreBasics and we will compare all the main features with .NET Framework, like the features below:

  • Project’s structure
  • Virtual directory
  • Views and HtmlHelpers
  • Controller and Actions
  • Routes
  • Web.config file
  • Dependency Injection

For this article I am using Visual Studio 2017 Community edition, .NET Framework 4.7.1 and .NET Core 2.2.

Creating an MVC ASP.NET Core C# project.

Creating an MVC ASP.NET Core C# project using Visual Studio 2017 is like building an MVC .NET Framework project. After clicking the New Project menu option, you need to choose ASP.NET Core Web Application, and you are good to go. Check it out.

.NET Core For .NET Developers

ASP.NET Core project’s structure

When we created an MVC ASP.NET Core project, we missed the web.config file. Another thing, there are two new folders wwwroot and Dependencies. And we can also see a new file called appsettings.json.

.NET Core For .NET Developers

It was easy to figure out what the Dependencies folder was. It works as the .NET Framework References folder does, referencing other libraries.

The second thing to do is to click on the wwwroot folder and see its contents. Without no surprise, it looks like the .NET Framework Content folder which stores images and CSS files.

Last but not least, let’s see the appsettings.json file. If you work a lot with .NET Framework, you know what App Settings mean. Yes, it is the same as the web.configAppSettings tag, a configuration file.

  1. {
  2.   “Logging”: {
  3.     “LogLevel”: {
  4.       “Default”“Warning”
  5.     }
  6.   },
  7.     “AllowedHosts”“*”
  8. }

As you can see, ASP.NET Core has just one JSON file to store all configuration for a web application.

Where is my web.config file???

Virtual directory

Following the steps of .NET developers, the next one is to compile the application and create a virtual directory on IIS. Let’s do it accessing the MVC project’s Web tab properties.

.NET Core For .NET Developers
If you tried to locate the Web tab to configure a virtual directory, you fell into my little trick. There is a Web tab in an MVC .NET Framework web application but in ASP.NET Core there isn’t.

One of the benefits of an ASP.NET Core application is that you don’t need to host it on IIS and reference the System.Web library anymore. Because of that, there is no virtual directory to configure.

With the .NET Core, you can also develop an application that runs in Windows, Linux, and Mac.

My first attempt to compile the ASP.NET Core application didn’t take much time. I pressed F5 to run the web application to see what happened, it worked!

.NET Core For .NET Developers

View HtmlHelpers

The next step is to open the Index and Layout files to see its contents. Nothing to comment about the Index file, but the Layout file is something different. Let’s take a closer look.

  1. <!DOCTYPE html>
  2. <html>
  3. <head>
  4.     <meta charset=“utf-8” />
  5.     <meta name=“viewport” content=“width=device-width, initial-scale=1.0” />
  6.     <title>@ViewData[“Title”] – FSL.NetCoreBasics.Mvc</title>
  7.     <environment include=“Development”>
  8.         <link rel=“stylesheet” href=“~/lib/bootstrap/dist/css/bootstrap.css” />
  9.     </environment>
  10. </head>
  11. <body>
  12.     <div class=“container”>
  13.         <partial name=“_CookieConsentPartial” />
  14.         <main role=“main” class=“pb-3”>
  15.             @RenderBody()
  16.         </main>
  17.     </div>
  18.     @RenderSection(“Scripts”, required: false)
  19. </body>
  20. </html>

If you see the Layout file, you can find new tags highlighted in bold that look like Angular and AngularJS tags. I am talking about the environment tag and the partial tag.

Some tag attributes are also highlighted in bold with an asp- prefix. We can find tag attributes like these in KnockoutJS, Vue, and Angular applications.

In the .NET Core MVC application, they are Tag Helpers.

  1. <a class=“nav-link text-dark” asp-area=“” asp-controller=“Home” asp-action=“Index”>Home</a>

In the .NET Framework MVC application, that responsibility is for Html Helpers, and the goal is the same, generate HTML code.

  1. @Html.ActionLink(“Home”, “Index”, “Home”, new { @class = “nav-link text-dark” })

Tag Helpers are more harmonious than Html Helpers.

Compare the code below to call a partial view in .NET Core and .NET Framework,

<partialname=”_CookieConsentPartial”/>
  1. @Html.Partial(“_CookieConsentPartial”)

Thank God Visual Studio highlights theses tags, if not, it would be a perfect mess to understand.

The RenderBody and RenderSection Html Helpers remains in .NET Core application. Maybe others too.

Controllers

Let’s move on. Until now we haven’t changed any line of code.

One thing about Controllers in .NET Core is that the Controllers doesn’t inherit from BaseControlleranymore, but from Controller.

Another thing almost hidden are the Actions in .NET Core are interfaces IActionResult which are not abstract classes ActionResult like .NET Framework.

  1. public class HomeController : Controller
  2.     {
  3.         public IActionResult Index()
  4.         {
  5.             return View();
  6.         }
  7.         public IActionResult Privacy()
  8.         {
  9.             return View();
  10.         }
  11.         [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
  12.         public IActionResult Error()
  13.         {
  14.             return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
  15.         }
  16.     }
I want to express my opinion here. In .NET Core, the Controller base class inherits from ControllerBase class. Well, good practices tell us to write our C# classes with the suffix of a base class. In this case, it should be better to call it BaseController.

Routes

All routes for the configuration of an MVC .NET Framework application are into the App_Start folder. The base route for an MVC application is,

  1. routes.MapRoute(
  2.     name: “Default”,
  3.     url: “{controller}/{action}/{id}”,
  4.     defaults: new { controller = “Home”, action = “Index”, id = UrlParameter.Optional }
  5. );

In an MVC .NET Core application, it looks like it is in .NET Framework. The default parameters and all configurations stay in just one line, check it out.

  1. routes.MapRoute(
  2.     name: “default”,
  3.     template: “{controller=Home}/{action=Index}/{id?}”);

The web.config file

It makes sense that we don’t have a web.config file. .NET Core doesn’t depend on IIS anymore. But how to configure all Connection Strings and App Setting on a .NET Core web application?

We need to configure all these thing’s tags on the appsetting.json file. I created the FslConfiguration tag as you can see on the code below. To read it from C# it is as easy as .NET Framework is.

  1. {
  2.   “Logging”: {
  3.     “LogLevel”: {
  4.       “Default”“Warning”
  5.     }
  6.   },
  7.     “AllowedHosts”“*”,
  8.     “FslConfiguration”: {
  9.         “IsCacheEnabled”true
  10.     },
  11.     “ConnectionStrings”: {
  12.         “Default”“Data Source=.\\(local);Initial Catalog=NetCoreBasics;User ID=sa;Password=dsf3432fr823@@2323;Persist Security Info=False;Connect Timeout=200000”
  13.     }
  14. }
The solution to reading tags from the appsettings.json file in C#, is creating a C# class with the same name and properties as we configured above.
  1. public sealed class FslConfiguration
  2. {
  3.     public bool IsCacheEnabled { getset; }
  4. }

Dependency Injection

The second step is creating a C# class to serialize the JSON format to C# object. I created an interface and a class thinking about Dependency Injection.

  1. public interface IConfigService
  2. {
  3.     Models.FslConfiguration GetConfig();
  4. }
  5. public sealed class NetCoreConfigService :
  6.     IConfigService
  7. {
  8.     private readonly IOptions<FslConfiguration> _config;
  9.     public NetCoreConfigService(
  10.         IOptions<FslConfiguration> config)
  11.     {
  12.         _config = config;
  13.     }
  14.     public FslConfiguration GetConfig()
  15.     {
  16.         return _config?.Value;
  17.     }
  18. }

Take a look into NetCoreConfigService constructor and see there is a typed interface as a parameter. That type is the FslConfiguration C# class.

So, to read any properties from the FslConfiguration app settings tag, I need to inject the IConfigurationService interface into any constructor I want to.

  1. public sealed class BusinessRuleService
  2. {
  3.     private readonly IConfigService _configService;
  4.     public BusinessRuleService(
  5.         IConfigService configService)
  6.     {
  7.         _configService = configService;
  8.         var isEnabled = _configService.GetConfig().IsCacheEnabled;
  9.     }
  10. }

One final step is that we must register the config service dependency injection, telling .NET Core that we will use NetCoreConfigService C# class everywhere we use the IConfigurationService interface. That configuration is on Startup.cs file.

  1. OptionsConfigurationServiceCollectionExtensions.Configure<FslConfiguration>(
  2.     services,
  3.     Configuration.GetSection(“FslConfiguration”));
  4. services.AddSingleton<IConfigService, NetCoreConfigService>();
The .NET Core has a built-in Dependency Injection feature, that means you don’t need to install other libraries like Simple Injector.

Source: prproject

blog.mousavi.fr

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s