Forem: Diógenes Polanco

nopCommerce CLI

Diógenes Polanco — Mon, 27 Sep 2021 13:56:06 +0000

The modern web developer's tool.

nopCommerce CLI is a development tool for build plugins for nopCommerce Solutions.

Development Setup

Prerequisites

Install [node.js]
Install [dotnet core]
Clone [nopCommerce]

Setting Up a Plugin of nopCommerce

Install the nopCommerce CLI globally:

$ npm install -g nopcli

Create plugin:

$ nopcli new -g=[GROUP NAME] -p=[PLUGIN NAME]

Build the plugin:

$ nopcli build -g=[GROUP NAME] -p=[PLUGIN NAME]

nopCommerce CLI is cross-platform, fast, scalable, has incredible tooling, and is loved by millions.

🙌 Use donations to help support this project! 🙌

Love nopCommerce CLI? Give our repo a star ⭐ ⬆️.

Which do you prefer vscode or Atom?

Diógenes Polanco — Mon, 02 Dec 2019 04:48:33 +0000

I have always had the need to find new tools for development purposes. They can be text editors, a library to manage tasks, a script to build an upcoming project, etc. The tools simplify the work environment and improve productivity at the same time. Among all text editors, Atom and Visual Studio Code are favorites among designers and developers. but is it interesting to know which one is preferred?

Fluent validation with NetCore

Diógenes Polanco — Sat, 23 Nov 2019 18:52:14 +0000

Validations are usually a repetitive and sometimes complex process, depending on the project and its architecture.

There are currently many libraries that allow you to automate the rules or validations that your project needs to achieve those milestones or functionalities.

The library that I currently use is a fluent validation call that allows me to create processes to validate and verify the data inserted by the user in the view. ASP.NET MVC provides several validation mechanisms, such as Remote Validation, Validation through data logging, Fluent Validation and Custom Validation. In this article, we will read about Fluent validation. The fluent validation contains .NET libraries and the validation is done using the Lambda expression. Use fluent validation when you want to create advanced and complex validation for user data.

Let's start these examples of use.

You can install it using the NuGet package manager console within Visual Studio or VSCode by running the following command:

dotnet add package FluentValidation

For example, imagine that you have a Product class:

 public class Product {
  public int Id { get; set; }
  public string Name { get; set; }
  public string Type { get; set; }
  public decimal Discount { get; set; }
  public decimal Price { get; set; }
}

You would define a set of validation rules for this class by inheriting from AbstractValidator:

using FluentValidation; 

public class ProductValidator : AbstractValidator<Product> {
}

The validation rules themselves should be defined in the validator class’s constructor.

To specify a validation rule for a particular property, call the RuleFor method, passing a lambda expression that indicates the property that you wish to validate. For example, to ensure that the Surname property is not null, the validator class would look like this:

using FluentValidation;

public class ProductValidator : AbstractValidator<Product> {
  public ProductValidator() {
    RuleFor(product => product.Name).NotNull();
  }
}

To run the validator, instantiate the validator object and call the Validate method, passing in the object to validate.

Product product = new Product();
ProductValidator validator = new ProductValidator();

ValidationResult result = validator.Validate(product);

The Validate method returns a ValidationResult object. This contains two properties:

IsValid - a boolean that says whether the validation suceeded.
Errors - a collection of ValidationFailure objects containing details about any validation failures. The following code would write any validation failures to the console:

Product product = new Product();
ProductValidator validator = new ProductValidator();

ValidationResult results = validator.Validate(product);

if(! results.IsValid) {
  foreach(var failure in results.Errors) {
    Console.WriteLine("Property " + failure.PropertyName)
    Console.WriteLine("Failed validation. Error was: " + failure.ErrorMessage);
  }
}

Use Fluent validation if you want to implement a complex or high level validation. I recommend using this library

the new features of AutoMapper in .net

Diógenes Polanco — Wed, 13 Nov 2019 20:34:59 +0000

    * [What is Automapper?](#Automapper)
    * [New features](#Features)
    * [Installation](#Installation)
    * [How to Use Automapper?](#AutomapperApplication)

What is Automapper?

AutoMapper is an object-object mapper. Object-object mapping works by transforming an input object of one type into an output object of a different type. What makes AutoMapper interesting is that it provides some interesting conventions to take the dirty work out of figuring out how to map type A to type B. As long as type B follows AutoMapper’s established convention, almost zero configuration is needed to map two types.

New features

    * Remove static API

the way to do it now is:

* Remove dynamic maps

the way to do it now is:

* Update Conditional Mapping

* Help the runtime find the AM assembly

    * Match destination enumerable types with it's enumerable for LINQ

Installation

The first step is to install the corresponding NuGet package:

dotnet add package AutoMapper --version 9.0.0

Now, what is the way to Use Automapper?

You can clone my code!

My recommended list of dotnet nugets packages

Diógenes Polanco — Thu, 07 Nov 2019 05:02:17 +0000

I remember that when I was a novice developer, my colleagues always told me that I had to write code without having to use Tools, Add-ons, IDE, DLL, etc. to get guides, good practices or maybe not redo the wheel. Well, times have changed and now developers, regardless of whether they are new or superior, do not have such prejudices, but today they dare to tell me why I do this in this way if there is already a package that solves it and it is really phenomenal all the packages you can find in nuget. So many solutions, algorithms and tools that make our lives easier every day.

So here I share my recommended list of dotnet nugets packages:

FluentValidation
- A validation library for .NET that uses a fluent interface to construct strongly-typed validation rules.
Autofac
- It manages the dependencies between classes so that applications stay easy to change as they grow in size and complexity.
NUnit
- fluent assert syntax, parameterized, generic and theory tests and is user-extensible.
Moq
- is the most popular and friendly mocking framework for .NET.
iTextSharp
- is a PDF library that allows you to CREATE, ADAPT, INSPECT and MAINTAIN documents in the Portable Document Format (PDF), allowing you to add PDF functionality to your software projects with ease.
Lib.AspNetCore.Security
- is a library which provides security features like Content Security Policy, Strict Transport Security or Expect-CT for ASP.NET
Swagger
- Middleware to expose Swagger JSON endpoints from API's built on ASP.NET.
Elmah
- is an application-wide error logging facility that is completely pluggable.
HtmlAgilityPack
- This is an agile HTML parser that builds a read/write DOM and supports plain XPATH or XSLT.
StackExchange.Redis
- High performance Redis client, incorporating both synchronous and asynchronous usage.
HangFire
- An easy and reliable way to perform fire-and-forget, delayed and recurring, long-running, short-running, CPU or I/O intensive tasks inside ASP.NET applications.
MiniProfiler
- Lightweight mini-profiler, designed for ASP.NET (including MVC) (non-.NET Core) websites
Audit.NET
- An extensible framework to audit executing operations in .NET and .NET Core.
EnterpriseLibrary.Common
- The Enterprise Library Common assembly contains elements that are shared among multiple application blocks.
EnterpriseLibrary.Data
- The Enterprise Library Data Access Application Block simplifies the development of tasks that implement common data access functionality.
Dapper
- A high performance Micro-ORM supporting SQL Server, MySQL, Sqlite, SqlCE, Firebird etc..
Npgsql
- Npgsql is the open source .NET data provider for PostgreSQL.
LinqKit
- LinqKit.EntityFramework contains extensions for LINQ to SQL and Entity Framework. Include(...) and IAsync are supported.
DocumentFormat.OpenXml
- The Open XML SDK provides tools for working with Office Word, Excel, and PowerPoint documents.
Newtonsoft.json
- Json.NET is a popular high-performance JSON framework for .NET
Unity
- This package contains Unity Container and Abstractions libraries as a single package.

What is your favorite operating system?

Diógenes Polanco — Tue, 05 Nov 2019 20:13:44 +0000

Implementing a Angular project with AspNet Core

Diógenes Polanco — Mon, 04 Nov 2019 15:13:20 +0000

This article will help us understand how to use the .NET Core command line interface to create and run an ASP.NET Core web application.

This way of implementing an Angular project provides a convenient starting point for ASP.NET Core applications that use Angular and the Angular CLI to implement a rich client-side user interface (UI).

The mechanism is equivalent to creating an ASP.NET Core project to act as an API back-end and an angular CLI project to act as an UI. This route offers the convenience of hosting both types of projects in a single application project. Consequently, the application project can be built and published as a single unit, which also allows us to deploy it to nopcommerce as a plugin.

You'll learn how to:

Create a web app project
How to use the SPA subdirectory approach
Add pages, images, styles, modules
Run the app
Publish and deploy

Create a web app project

Open a command shell, and enter the following command:

dotnet new angular

Run dotnet build to verify the app builds correctly. On the first run, the build process restores npm dependencies, which can take several minutes. Subsequent builds are much faster.

Run dotnet run to start the app. A message similar to the following is logged:

Now listening on: http://localhost:<port>

Navigate to this URL in a browser.

In ASP.NET Core, supporting SPAs works via a middleware to then point to this directory (no matter what you call it). It does this by injecting the middleware as the last step in Startup’s Configure method:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.HttpsPolicy;
using Microsoft.AspNetCore.SpaServices.AngularCli;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

namespace test
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllersWithViews();
            // In production, the Angular files will be served from this directory
            services.AddSpaStaticFiles(configuration =>
            {
                configuration.RootPath = "ClientApp/dist";
            });
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
                app.UseHsts();
            }

            app.UseHttpsRedirection();
            app.UseStaticFiles();
            if (!env.IsDevelopment())
            {
                app.UseSpaStaticFiles();
            }

            app.UseRouting();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllerRoute(
                    name: "default",
                    pattern: "{controller}/{action=Index}/{id?}");
            });

            app.UseSpa(spa =>
            {
                // To learn more about options for serving an Angular SPA from ASP.NET Core,
                // see https://go.microsoft.com/fwlink/?linkid=864501

                spa.Options.SourcePath = "ClientApp";

                if (env.IsDevelopment())
                {
                    spa.UseAngularCliServer(npmScript: "start");
                }
            });
        }
    }
}

This involves two calls: UseSpaStaticFiles and UseSpa. These calls set up the ability to get calls from a generated index.html that Angular-CLI builds for you. In this case, you’ll see that during development, it will launch ‘npm start’ for you; that is part of how it launches the development build of the Angular app.

While the middleware is a good option if you’re building a single, monolithic SPA without much use for other web pages, I think for most developers, integrating ASP.NET Core into a traditional MVC application makes the most sense. You can typically keep an SPA as a separate folder and treat it as a child-project, without having to do a lot of integration between the two projects.

How to use the SPA subdirectory approach

suppose you have an Angular project in a subdirectory called ClientApp.

Because this directory has its own package.json, you can just use the CLI of the library you’re working with to do builds and such. You could even develop it in isolation without invoking the ASP.NET Core project, but since I’m usually adding the SPA to an existing Razor view, I generally just run them both.

One issue with this method is that the build directory for the SPA project is usually in this directory. You could use the SpaStaticFiles middleware to solve this, but I usually just change the configuration of the SPA to build into my wwwroot directory. For example, this is what that looks like in the angular.json file (for the Vue.js CLI):

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "version": 1,
  "newProjectRoot": "projects",
  "projects": {
    "test": {
      "root": "",
      "sourceRoot": "src",
      "projectType": "application",
      "prefix": "app",
      "schematics": {},
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "progress": true,
            "extractCss": true,
            "outputPath": "dist",
            "index": "src/index.html",
            "main": "src/main.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.app.json",
            "assets": ["src/assets"],
            "styles": [
              "node_modules/bootstrap/dist/css/bootstrap.min.css",
              "src/styles.css"
            ],
            "scripts": []
          },
          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            }
          }
        },
        "serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "test:build"
          },
          "configurations": {
            "production": {
              "browserTarget": "test:build:production"
            }
          }
        },
        "extract-i18n": {
          "builder": "@angular-devkit/build-angular:extract-i18n",
          "options": {
            "browserTarget": "test:build"
          }
        },
        "test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.spec.json",
            "karmaConfig": "src/karma.conf.js",
            "styles": ["styles.css"],
            "scripts": [],
            "assets": ["src/assets"]
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": ["src/tsconfig.app.json", "src/tsconfig.spec.json"],
            "exclude": ["**/node_modules/**"]
          }
        },
        "server": {
          "builder": "@angular-devkit/build-angular:server",
          "options": {
            "outputPath": "dist-server",
            "main": "src/main.ts",
            "tsConfig": "src/tsconfig.server.json"
          },
          "configurations": {
            "dev": {
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "namedChunks": false,
              "extractLicenses": true,
              "vendorChunk": true
            },
            "production": {
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "namedChunks": false,
              "extractLicenses": true,
              "vendorChunk": false
            }
          }
        }
      }
    },
    "test-e2e": {
      "root": "e2e/",
      "projectType": "application",
      "architect": {
        "e2e": {
          "builder": "@angular-devkit/build-angular:protractor",
          "options": {
            "protractorConfig": "e2e/protractor.conf.js",
            "devServerTarget": "test:serve"
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": "e2e/tsconfig.e2e.json",
            "exclude": ["**/node_modules/**"]
          }
        }
      }
    }
  },
  "defaultProject": "test"
}

In this case, I’m just telling the Vue.js CLI to output the build to a subdirectory of the js folder in wwwroot, so I don’t need to configure ASP.NET Core to look into the SPA directory directly. Angular and React both support this kind of output directory, if you don’t want to use the SpaStaticFiles middleware.

By using one or more subdirectories with their own build, you can have many SPA projects (even if they’re different frameworks) in one ASP.NET Core project. But it does have some limitations involving deployment and dependency management. By doing this, each project will have it’s own node_modules directory which means that build times can get very lengthy.

Because you’re configuring the output directory into wwwroot, you don’t need to specify including a directory when you deploy the project, but you will need to tell the MSBuild (e.g. csproj file) to build the SPA project before you deploy. The trick here is to add a Target to your .csproj file:

  <Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
    <!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build -- --prod" />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build:ssr -- --prod" Condition=" '$(BuildServerSideRenderer)' == 'true' " />

    <!-- Include the newly-built files in the publish output -->
    <ItemGroup>
      <DistFiles Include="$(SpaRoot)dist\**; $(SpaRoot)dist-server\**" />
      <DistFiles Include="$(SpaRoot)node_modules\**" Condition="'$(BuildServerSideRenderer)' == 'true'" />
      <ResolvedFileToPublish Include="@(DistFiles->'%(FullPath)')" Exclude="@(ResolvedFileToPublish)">
        <RelativePath>%(DistFiles.Identity)</RelativePath>
        <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
        <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
      </ResolvedFileToPublish>
    </ItemGroup>
  </Target>

The Target specifies that it should consider something before it computes the files to publish (so before it looks at wwwroot for the files to include). The two ‘Exec’ lines are just a way to run the install and build steps in the ClientApp directory. This is only executed during a publish, so it won’t impact your development cycle.

The big drawback is more about Visual Studio than about ASP.NET Core. Because the project.json is in a subdirectory (not in the root of the ASP.NET Core project), you can’t get the Task Runner Explorer to find the build. This means you’ll have to run it separately. If you’re using Visual Studio Code, Rider, or other IDE, you might already be used to opening console/terminal windows and doing the build yourself so this might not be much of a hardship.

The other limitation is related to this one, more than one package.json to manage. This is the one that hurts me the most. Most of my ASP.NET Core projects already use NPM to manage other dependencies (both dev and production dependencies). Having to manage two or more package.json files makes me a little frustrated. That’s why I usually resolve to use the last of the options — fully integrate the SPA into the ASP.NET Core project.

Add pages, images, styles, modules

The ClientApp directory contains a standard Angular CLI app. See the official Angular documentation for more information.

There are slight differences between the Angular app created by this template and the one created by Angular CLI itself (via ng new); however, the app's capabilities are unchanged. The app created by the template contains a Bootstrap-based layout and a basic routing example.

Run the app

If you have the ng tool installed globally, you can run any of its commands. For example, you can run ng lint, ng test, or any of the other Angular CLI commands. There's no need to run ng serve though, because your ASP.NET Core app deals with serving both server-side and client-side parts of your app. Internally, it uses ng serve in development.

If you don't have the ng tool installed, run npm run ng instead. For example, you can run npm run ng lint or npm run ng test.

In a command prompt, switch to the ClientApp subdirectory:

cd ClientApp && npm start

Use npm start to launch the Angular CLI development server, not ng serve, so that the configuration in package.json is respected. To pass additional parameters to the Angular CLI server, add them to the relevant scripts line in your package.json file.

Publish and deploy

In development, the app runs in a mode optimized for developer convenience. For example, JavaScript bundles include source maps (so that when debugging, you can see your original TypeScript code). The app watches for TypeScript, HTML, and CSS file changes on disk and automatically recompiles and reloads when it sees those files change.

In production, serve a version of your app that's optimized for performance. This is configured to happen automatically. When you publish, the build configuration emits a minified, ahead-of-time (AoT) compiled build of your client-side code. Unlike the development build, the production build doesn't require Node.js to be installed on the server (unless you have enabled server-side rendering (SSR)).

I will soon be publishing the code on GitHub and some extra steps to deploy it in the cloud ...

How to develop a plugin for NopCommerce

Diógenes Polanco — Sat, 26 Oct 2019 01:33:22 +0000

The add-ons are specialized modules which maximize the functionality of nopcommerce such as payment processors, shipping provider, etc.

Before launching the code, it is necessary to know the following of nopcommerce:

Architecture of nopCommerce
Types of plugin
Register new routes
The plugin structure, required files, and locations
Understanding Layout / Design
Handling "Install" and "Uninstall" methods
Handling requests. Controllers, models and views

Architecture of nopCommerce

It is an open source e-commerce, so you can download from github without any inconvenience and even collaborate. Projects and folders are listed in the order in which they appear in Visual Studio. To build a plugin my recommendation is not to change the source code of the libraries of the solution framework.

\Libraries\Nop.Core

The Nop.Core project contains a set of core classes for nopCommerce, such as caching, events, helpers, and business objects (for example, Order and Customer entities).

\Libraries\Nop.Data

The Nop.Data project contains a set of classes and functions for reading from and writing to a database or other data store. It helps separate data-access logic from your business objects.

\Libraries\Nop.Services

This project contains a set of core services, business logic, validations or calculations related with the data, if needed. Some people call it Business Access Layer (BAL).

Projects into \Plugins\ solution folder

\Plugins is a Visual Studio solution folder that contains plugin projects. Physically it's located in the root of your solution. But plugins DLLs are automatically copied in \Presentation\Nop.Web\Plugins\ directory which is used for already deployed plugins because the build output paths of all plugins are set to ..\..\Presentation\Nop.Web\Plugins\{Group}.{Name}\. This allows plugins to contain some external files, such as static content (CSS or JS files) without having to copy files between projects to be able to run the project.

\Presentation\Nop.Web

Nop.Web is an MVC web application project, a presentation layer for public store which also contains administration panel included as an area. If you haven't used ASP.NET before, please find more info here. This is the application that you actually run. It is the startup project of the application.

\Presentation\Nop.Web.Framework

Nop.Web.Framework is a class library project containing some common presentation things for Nop.Web project.

\Test\Nop.Core.Tests

Nop.Core.Tests is the test project for the Nop.Core project.

\Test\Nop.Services.Tests

Nop.Services.Tests is the test project for the Nop.Services project.

\Test\Nop.Tests

Nop.Tests is a class library project containing some common test classes and helpers for other test projects. It does not have any test.

\Test\Nop.Web.MVC.Tests

Nop.Web.MVC.Tests is the test project for the presentation layer projects.

Types of plugin

The type of its complement is defined by the interface that implements the main complement class.

Discount Rules (IDiscountRequirementRule)For defining requirements that must be met my an order for a discount to be applied

Exchange Rate Prodider (IExchangeRateProvider)For getting the exchange rates for currencies

External Authentication Method (IExternalAuthenticationMethod)For adding new external authentication methods (e.g. “Login with Facebook”)

Widgets (IWidgetsPlugin)For when your plugin doesn’t fit any of the other types

Payment Method (IPaymentMethod)For example, Paypal or Worldpay

Shipping Rate Computation Method (IShippingRateComputationMethod)For calculating shipping rates (many plugins of this time call web services provided by couriers to retrieve rates)

Pickup points is an option providing customers the flexibility to select a point where they can receive parcels.

Tax Provider (ITaxProvider)For calculating tax rates

Widget (IWidgetPlugin)Widgets are blocks of content shown throughout the site. The default theme contains many widget “areas”.
You can assign your new widget to one of these areas, and wherever the area is referenced in the theme, your widget will appear.

Register new routes

ASP.NET Core routing is responsible for assigning incoming browser requests via a get to the MVC controller. NopCommerce has an IRouteProvider interface that is used for route registration during application startup. All main routes are registered in the RouteProvider class located in the Nop.Web project.

The plugin structure, required files, and locations

First thing you need to do is to create a new "Class Library" project in the solution. It's a good practice to place all plugins into \Plugins directory in the root of your solution (do not mix up with \Plugins subdirectory located in \Nop.Web directory which is used for already deployed plugins). It's a good practice to place all plugins into "Plugins" solution folder (you can find more information about solution folders here).

A recommended name for a plugin project is "Nop.Plugin.{Group}.{Name}". {Group} is your plugin group (for example, "Payment" or "Shipping"). {Name} is your plugin name (for example, "PayPalStandard"). For example, PayPal Standard payment plugin has the following name: Nop.Plugin.Payments.PayPalStandard. But please note that it's not a requirement. And you can choose any name for a plugin. For example, "MyCustomPlugin".

Once the plugin project is created you have to open its .csproj file in any text editor and replace its content with the following one:

The next step is creating a plugin.json file required for each plugin. This file contains meta information describing your plugin. Just copy this file from any other existing plugin and modify it for your needs. For example, PayPal Standard payment plugin has the following plugin.json file:

Add a class MyCustomPlugin.cs and use the following code:

Handling "Install" and "Uninstall" methods

Some plugins can require additional logic during plugin installation. For example, a plugin can insert new locale resources. So open your IPlugin implementation (in most case it'll be derived from BasePlugin class) and override the following methods:

Install. This method will be invoked during plugin installation. You can initialize any settings here, insert new locale resources, or create some new database tables (if required).
Uninstall. This method will be invoked during plugin uninstallation.

Understanding Layout / Design

What are layouts? Every web developer/designer wants to maintain a consistent look and feel across all of the pages within the website. Back in the days, the concept of "Master Pages" was introduced in ASP.NET 2.0 which helps in maintaining a consistent look of the website by mapping it with .aspx pages.

Razor also supports this similar concept with a feature called "Layouts". Basically, it allows you to define a common site template and then inherit its look and feel across all the views/pages on your website.

In nopCommerce, there are 2 different kinds of layouts:

_ColumnsOne.cshtml
_ColumnsTwo.cshtml

All these 2 layouts are inherited from one main layout called: _Root.cshtml. The _Root.cshtml itself is inherited from _Root.Head.cshtml. _Root.Head.cshtml is the file you need to look into if you are linked css stylesheet and jquery files (you can add/link more .css and .js files here). The location of all these layouts in nopCommerce is as follows: nopCommerce root directory/Views/Shared/.... If you are using source code version then: \Presentation\Nop.Web\Views\Shared\...

Handling requests. Controllers, models and views

Add a class MyCustomPluginController.cs (in folder “Controllers” within your plugin) and use the following code:

Add a Configure.cshtml (View) – In this case we are creating a blank plugin.

Now, we will add the menu item by adding this code in “MyCustomPlugin.cs”:

We can see our menu item here:

Let’s create a “WidgetsMyCustomPluginViewComponent” file inside the “Components” folder of your custom plugin and simply paste the default home view (PublicInfo.cshtml) from Nop.Web like this:

Note: Make sure the output directory (in properties) for your home view (PublicInfo.cshtml) is defined as “Copy if newer”. Rebuild your plugin and try going to your public store (since your plugin is already installed)

We should see the plugin view overriding the default home view like this:

I let you share the source code link on GitHub

Creating a NopCommerce plugin with .Net Core and Angular - Part I

Diógenes Polanco — Fri, 18 Oct 2019 02:55:14 +0000

Objective:

We will create a plugin for nopcommerce taking advantage of the power of aspnet core and the angular fluids for the frontend. We will create a plugin that will import the products from an external service.

You have to understand how to:

Create a plugin for nopCommerce?

The add-ons are specialized modules which maximize the functionality of nopcommerce such as payment processors, shipping provider, etc. Currently you can take advantage of their official documentation by entering this link.

Develop a webapp with AspNet Core?

The applications with asp net core are very easy to develop these days and when I say easy it is because I remember how it was a bit complex to develop with aspnet in the previous versions. but in another article I will talk about the differences between .Net vs .Net Core. So for the purposes you must also have basic knowledge of aspnet core and can start with this link.

Project Architecture

The product importer plugin is responsible for extracting the products from the ODataProducts service and rules configured in the plugin to upload them to the nopcommerce catalog.

Source code

This plugin only has one component that is responsible for importing the products of the external service so we will only have to develop a class that has the functionality to synchronize the products of the service against the nopcommerce catalog for that we will use C#.

You have to create a console test project in which we will do the service.

Let's execute the following commands:

~/ProductsImport$ dotnet  new console

~/ProductsImport$ dotnet add package Newtonsoft.Json

We will create the following classes: