There are two ways to manage changes or modifications to a nopCommerce system. The first is by making plugins which add to or override the existing functionality of the core system. nopCommerce core design allows you to do this using a number of methods. In this case all the new code changes, additions, pages and new views are packaged up together and uploaded using the nopCommerce plugin systems
Refer to https://docs.nopcommerce.com/en/getting-started/advanced-configuration/plugins-in-nopcommerce.html
The other way is to make changes to the nopCommerce core. This is done in the same way as any other website system. i.e. you need to replace the files in your production website with the files that have been changed in the development system. There are many standard ways of doing this but basically through the development process files are changed. Either .cshtml views or .cs source files or .css style files, or what is name .dll or called binary files, etc.
Once the files have been changed you need to work out which files have changed in the overall system then upload those changed files to the production website. As a developer you should understand what files you are changing and what will be the result of those changes
In most cases if you change a .cshtml file or .css file etc, then you know the files you have changed and it is easy to take these files and upload to the website.
In the case where you change .cs files then you need a tool like Visual Studio which compiles and links the changes made in the source files and create what is called a new Binary file or .dll file. This process is called building or rebuilding project. It is this resultant file of this process that needs to be uploaded to the website.
The core design of nopCommerce is based upon the setup and use of Visual Studio projects. There are four main projects that build a nopCommerce system which follows the standard methodologies. They are Core, Services, Data and Web. All the source code that is part of nopCommerce is dived into these four main project areas. Likewise when the source code is built the resultant binary code will end up in one of the four main .dll’s i.e. Nop.Core.dll, Nop.Services.dll, Nop.Data.dll and Nop.Web.dll
Of course this is a very simplified and there are many more .dll’s, support files, configuration and other files which make a website work. But basically when you change a source file you rebuild the project and create a new .dll.
Then you need to move that new .dll that is created to the production system. Thankfully there are a number tools which allow you manage this process.
There is also another process called publishing the website which essentially takes and combines all the files that are needed to run the website along with any other support or configuration files and then packages them together and allows the next step of moving them to development.
Again there are many way to do this and many tools which can help including publishing directly to the remote production website.
One of these processes involved publishing to a local directory first and then from that local directory move only the files that have changed, as we have described to the remote development website.
This is the process I use. When I have completed the development and testing for a change in nopCommerce core then I publish to a local directory. From that local directory I then determine the files that have changed and then only copy the changed files to remote production.
In most cases I will know what files have been changed in the local publish and can easily copy the one or two .dlls that have changed and the .cshtml views or .css files that have changed to remote production. Another way to check what files have changed is using the windows search to sort the local published directory by time. You know that you have just published today and so you can order the files and work out what files have been changed today. Then copy those files or ftp those file to the remote production website. After the files have been copied then you need to restart the remote production system to see the effects.
That’s it, the changes have been made. Hopefully you have tested it all and there will be no problems.
Of course before you have overwritten and files in the remote production system then you will have taken a backup either as individual files or a backup of the complete system. So that if there is a problem you can remove and replace the files you have changed with the backup version and restart again.
As I have said there are many tools that can be used for the above process including webdeploy and azure development, etc which are described elsewhere.
The reason I publish to a local directory is that it allows me to keep many different versions of the published website created during the lifecycle of development over time and hence the configuration of the website at a certain point in time, which you can go back to in case there are problems.
Having a good understating of how Visual Studio works and the many features and its inbuilt tools is key to doing the job. See https://visualstudio.microsoft.com/vs/getting-started/
Other tools and systems like GitHub also can be helpful is maintaining the source code base See https://docs.github.com/en/get-started
Ultimately it is the developers job to keep track of all the above tools, ways and processes over time, keeping it all together and understanding the ramifications of any change in the source code and underlying files and what affect that might have when upgrades are made in the production system.
