Create nopCommerce nuget package

Hi,

as developer i think it would be nice to have a nuget package for nopCommerce.

I think this package should containing the following assemblies:

Nop.Core.dll
Nop.Data.dll
Nop.Services.dll
Nop.Web.Framework.dll

and eventually add dependencies to AutoFac, Fluentvalidation etc...

What do you think nopDev Team?

But who will use them? And why (in nuget)?

It will be used by plugin developers who want to have the nop assemblies in their solution.

Now if i want to write a plugin i have to download a (specific) nop version, take the dll's i need and copy them in a Reference folder.

Obviously you can developing using the nop Source and add your plugin ploject to the solution, but this is a lot heavier and with a nuget package the plugin solution can be " stand alone"

But can you write a plugin without the entire solution? What web application will you run in order to test it? Anyway you need the entire solution

I wrote my plugins as stand-alone solutions with the nop assemblies placed in a reference folder.

To test my plugin i make a post build event or a batch script to copy my assemblies in the plugin folder of my nop installation and then i can debug/test it.

Doing so i'm able to keep everything i need just in my plugin solution, and if a nuget nop package will be available then a developer can upgrade easily when a new version is released, directly from visual studio using nuget.

Thanks a lot for info. I'll think about it

I created a nuget package for plugins developing.
Instead to add  dll's manually each time just use this package (also useful when you need to upgrade plugin to next nop version)

Install-Package NopCommerce.Core


http://www.nuget.org/packages/NopCommerce.Core/

Also you can add post build events to your project to copy dll's and views to plugin folder.

robocopy "$(ProjectDir)bin" "C:\inetpub\wwwroot\dev.nopcommerce.com\bin" "$(TargetFileName)"  /E /XO /XD ".svn"  
robocopy "$(ProjectDir)bin" "C:\inetpub\wwwroot\dev.nopcommerce.com\Plugins\Payments.MyPlugin" "$(TargetFileName)"  /E /XO /XD ".svn"  
robocopy "$(ProjectDir)Views" "C:\inetpub\wwwroot\dev.nopcommerce.com\Plugins\Payments.MyPlugin\Views" "*.*"  /E /XO /XD ".svn"  
exit 0

I don't like to "Reload plugin lists" on each build, so i add copy to bin also

Yarik

When are you going to release 3.8 nuget version ?

I know that this is an old thread, but I felt that I needed to comment.

I've been doing a lot of work recently with a CMS system called Cofoundry (cofoundry.org). It comes as 4 Nuget packages (Cofoundry.Core, .Domain, .Web & .Admin), or if you want to customise the base code you can fork from the public repo. Plugins are also available as Nuget packages (or as code from a repo). The only thing that you can't do with plugins is install them on the fly, which to me isn't an issue as I want to ensure that all code gets built and tested via a CI pipeline.

One great advantage with the Nuget package approach that Cofoundry uses is that it leaves you with a clean web project that only contains the things that you need to customise (e.g. Views and stylesheets - these can be installed from a template via the dotnet new command). Any custom business objects and services etc. can also be implemented within this project (although I prefer to separate them out into class libraries), but totally segregated from the Cofoundry implementation.

Whilst I think that NopCommerce is a great platform, containing a lot of features and in the most part well written, I have had a few issues...

1. Visual Studio Performance
Having the entire NopCommerce solution loaded alongside any custom code gives a huge performance overhead that in my case is unnecessary (whilst I realise that some developers will want to amend the base NopCommerce code, I would rather add/change functionality by extending it in some way via additional libraries).

2. Merge Hell
I've just tried to upgrade a project to the 4.4 beta - this caused 10,000 merge conflicts. I haven't got time for that! With Cofoundry, the upgrade process is simple - update all Nuget packages in the solution to the required version, make any adjustments needed for change in dotnet version, fix any breaking changes (all documented on their website).

3. Referencing Nop.Web from a plugin
Sometimes I need to reference Nop.Web from a plugin. The plugin is then installed into Nop.Web and therefore I have a circular dependency. This seems bad to me, but sometimes I need to do it.  Examples of why this is necessary are referencing a model, or overriding a controller within Nop.Web. I'd rather see the code behind the frontend moved into a class library.

Where I'm going with this...

Well, this weekend I've taken the time to download the beta 4.4 source and create Nuget packages from it. I've created the following packages:

Nop.Core
Nop.Data
Nop.Services
Nop.Web.Framework
Nop.Web

The Nop.Web package contains eveything from the Nop.Web project except for the App_Data, Areas/Admin/Views, gulp, logs, Plugins, Themes & Views folders which have been moved to a separate Web project, along with Startup, Program, gulpfile.js and package.json. The Sdk was also changed on Nop.Web to 'Microsoft.NET.Sdk' to make it into a class library (and the relevent parts of the .proj file moved to the web project).

Initial tests have been successful and it's certainly helping with Visual Studio performance. I'm now going to try using the packages on a project that we currently have in development, and if that works then the real test will be seeing how easy an upgrade is when the final v4.4 is released.

I really think that the NopCommerce team should consider releasing Nuget Packages as I'm sure that there must be other developers out there who would prefer to take this approach.