Enterprise Framework

Software Solutions in the Enterprise

How To : NuGet Best Practices for Adding To New or Existing Projects

09 August 2016 Robert Amiscaray (0)
How To : NuGet Best Practices For Adding to New or Existing Projects

Keeping Nuget packages consistent in your solution is critical.  A lot of devs even now and days do it the hard way by going to the individual projects and trying to manage the Packages that way.  Managing NuGet packages in your solutions is easier than you think it is and will reduce headaches of DLL hell.

Packages in Source Control

  • DO NOT put NuGet packages into Source Control.  Exclude the Packages folder from the Solution root before checking in.  Whenever your solution is pulled fresh from source control, it will determine the packages don't exist and try to pull them down automatically if they are from the public NuGet servers.
  • DO NOT distribute packages with your code unless they are from your internal NuGet server and you are giving it to a client or something.
Using Visual Studio 2015

  • Right click the Solution > Choose Manage NuGet Packages for Solution.
  • Click Installed, this will show you all of the NuGet packages in the left column currently used by all projects in the solution.  The right column displays a list of the projects and the NuGet package version that is installed next to it.  
  • In the left column, choose a NuGet Package (Example:  Newtonsoft.Json)   
  • In the right column in the list of projects, you should scroll down and ensure that all the version numbers are the same across all projects, if they are not, you really should update them.  You can do this by putting a check next to the project with a older NuGet version.  Then in Version row, choose the one that matches the other projects in the solutions and click, 
NOTE:  Before updating packages you should finish any development work you are on before messing with NuGet Packages.  

Summary:  
  • DO NOT include the NuGet Packages folder in source control.  
  • DO NOT distribute NuGet Packages unless from internal NuGet server and you need to.
  • Use Manage NuGet Packages for solution to determine which NuGet packages and versions are being used across projects.  
  • Sync NuGet package versions across projects (Checkin Dev work before messing with Packages).


NopCommerce Plugin Best Practices

05 August 2016 Robert Amiscaray (0)
NopCommerce Plugin Best Practices

NOTE:  DRAFT IN PROGRESS

Versions:    3.7

What are NopCommerce Plugins?

  • NopCommerce plugin are components that can extend the core NopCommerce E-Commerce platform.
  • NopCommerce Plugins can be used to add, extend or replace features within NopCommerce
  • NopCommerce Plugins are mini MVC components, it can use Controllers, Views, Routes, Models, and JavaScript that you would typically include within a ASP.NET MVC App.
  • NopCommerce Plugins are registered within NopCommerce dynamically and then installed through configuration for use within your NopCommerce application.

What types of NopCommerce Plugins can you create?

  • Admin Plugin - Allow you create new screens for use on the Admin page or even replace existing Admin features.
  • Retail Product Plugin - Allows you create new screens or overwrite existing retail product page features
  • Checkout Plugin - Allows you add to checkout or replace existing checkout.
  • Web Service Plugin - Create a RESTful Web API end point.
  • Mixed plugin - A combination of plugins for use in your NopCommerce site.
  • more...

What are the advantages of using a Plugin
  • A isolated set of features that are distribute-able (Assuming you kept references clean)
  • A isolated set of features that aren't impacted by a NopCommerce upgrade (hopefully)
  • You can replace NopCommerce endpoint calls and replace it with a custom one in your plugin.
  • Easy way to add non-core tables to the system

What are the dis-advantages of using a Plugin
  • Replacing the Checkout process with a plugin is probably not the greatest idea.
  • No Referential Integrity against existing Nop tables
  • Plugins that intercept core NopCommerce endpoints can become a maintenance nightmare.
 
Custom Plugin development challenges. 

You should follow these rules to try and minimize work

  1. Use the same Nuget package versions across all projects.  Follow NuGet Best Practices.  By not managing NuGet Packages correct could result in weird behaviors in your application.
  2. DO NOT checkin the NuGet package into source control.
  3. No not directly reference DLL's in the Packges folder, use the NuGet to include
  4. Your plugin should encapsulate all the logic required to operate
  5. Minimize changes to the core NopCommerce code base
  6. Controllers should be responsible for hydrating the current session/request and then passing that information down to helper services.
  7. Controllers should not contain your business logic because it's hard to test
  8. Services that contain logic should not be aware of HTTP Context and Session.
  9. Minimize size of methods (SOLID principle)
  10. Using a Plugin to override the Checkout Workflow is a complex task and should be a last resort.

Custom Plugin Endpoints

  • Do NOT start custom route End Points with the word Admin.  
routes.MapRoute("Plugins.MyCompany.Admin.Product.List",
     "Admin/MyPlugin/Product/List",
     new { controller = "MyProduct", action = "Admin" },
     new[] { "MyCompany.Plugin.Misc.PluginName.Controllers" }
);
  • Start custom routes End Points with the word Plugins
routes.MapRoute("Plugins.MyCompany.Admin.Product.List",
     "Plugins/MyPlugin/Product/List",
     new { controller = "MyProduct", action = "Admin" },
     new[] { "MyCompany.Plugin.Misc.PluginName.Controllers" }
);

Base Plugin Folder and File Structure

  • \Content
  • \Controllers
  • \Extensions
  • \Infrastructure
  • \Models
  • \Scripts
  • \Services
  • \Validators
  • \Views
  • \Sql
  • Description.txt
  • Logo.png
  • Notes.Txt
  • packages.config
  • RouteProvider.cs

Routes



Resources