Probably the hottest topic in the Umbraco community right now has got to be the inevitable move to .NET Core, and with it finally moving into it's Beta phase, now is the time we can really start to review the upcoming changes and start to make a plan of action on how we get Vendr .NET Core and v9 ready.

The Challenge

Whilst the new framework brings a lot of code changes, this in reality is the easy part of the migration. Updating existing code to use the newer API's is mostly a case of researching alternatives and implementing the changes. The bigger challenges for us comes mostly in the project management side of things.

Whilst planning our strategy to move to .NET Core, we have done so with several key requirements in mind which we believe are essential to ensure the project remains agile and maintainable moving forwards.

Those requirements are:

1. We must ensure new features are implemented on both the v8 and v9 versions of the Vendr product. With Vendr only being 1 year old, many existing customers bought into Vendr with the understanding that continued improvements would be made, and many of these customers will remain on the v8 version of Umbraco.
2. We must do what we can to reduce the maintenance cost of the various Vendr add-ons, especially the Vendr Payment Providers and try and avoid the need to manage multiple versions. As a small team, we can't afford to have overly complicated management processes for these projects.
3. We must do what we can to ensure the Vendr project remains agile and can continue to be deployed with ease to ensure we maintain our ability to rollout fixes and updates rapidly.

Our Solution

In order to meet these requirements we believe the best approach we can take is to go with a single code base, dual targeted package strategy.

By working from a single code base, this will ensure that any features we develop / fixes we implement will ALWAYS be implemented for both the v8 and v9 versions at the same time, and because the code bases will be aligned, implementing these changes will be much more straight forward. In addition, the single code base allows us to extract a common core, .NET Standard project which can be used by both the v8 and v9 versions of the platform reducing maintenance costs but more importantly will provide a single shared dependency for code based add-ons like Payment Providers, which means these only need to be developed once for this shared core and will "just work" for both versions of Vendr.

Finally, by working from a single code base, it also allows us to simplify our deployment strategy, only requiring a single deployment process, and maintaining a single set of shared product version numbers.

From a package perspective what this means is that from Vendr v2.0.0, all NuGet (and hopefully Umbraco) packages will be installable on both v8 and v9 versions of Umbraco with the install process determining which implementation to actually use. By having a single set of packages, this also helps to reduce any confusion over which versions of a package should be installed in which environments.

How We Get There

In order to get to this single code base however there will need to be some breaking changes in the project / package structure, and unfortunately this won't be limited to just those using the v9 version of Vendr. Existing Vendr customer on Umbraco v8 wishing to upgrade to Vendr 2.0.0 will need to be aware of, and update their references accordingly.

Whilst this is unfortunate, we do believe it is necessary to prepare everyone for the move to .NET Core.

Current Project Structure

In the current v8 version of Vendr, the solution is broken down into the following projects:

• Vendr.Core
  • The core project where models, persistence, services and API's are all defined and implemented
• Vendr.Core.Web
  • The project where any core Vendr related web logic exists such as payment provider callback routes
• Vendr.Web
  • The project where anything Umbraco UI would live such as the UI, discount providers and property editors
• Vendr.Web.UI
  • The back office and front end UI files

Much of this project structure was chosen for the sake of simplicity, however this unfortunately doesn't map well into a structure that would work for our future requirements. In addition, as we've learnt more over the first year of it's development, we have found the limitations of this structure and have multiple areas of code that could be better structured.

Proposed Project Structure

For our next version of Vendr we are proposing the following structure that not only restructures the code base to fulfill our requirements, but also addressed a number of improvements to our initial approach.

• Vendr.Core (.NET Standard)
  • Models
  • Interfaces
  • Services
  • Extensions
  • etc
• Vendr.Infrastructure (.NET Framework + .NET Core)
  • Interface implementations with 3rd party dependencies (non Umbraco)
  • Repositories
  • DB Transfer objects
  • DB Mappers
• Vendr.Web (.NET Framework + .NET Core)
  • Common web related elements / extensions / helpers
• Vendr.Umbraco (.NET Framework + .NET Core)
  • Umbraco implementations of services
  • Property editors
  • Package actions
  • Value Converters
  • Cache Refreshers
  • Migrations
• Vendr.Umbraco.Web (.NET Framework + .NET Core)
  • Configuration
    • Front End Umbraco API routes
  • Back office web logic
    • Sections
    • Controllers
    • Trees
    • ViewModels/DTOs
    • View Model Mappers
    • etc
• Vendr.Umbraco.Web.UI
  • Front end UI files specific to Umbraco Views
    • Email Templates
    • Print Templates
    • Export Templates
  • Back office UI files: App_Plugins\Vendr
    • Angular
    • CSS
    • HTML

NB Whilst some of these updates are not strictly required to meet our .NET Core requirements, we believe that given a structural breaking change is already necessary that it is better to take advantage of this now and create a structure that can lead this project into the future, rather than just implementing the bare minimum and requiring future breaking changes.

Packages

From a package perspective, most of the NuGet packages follow the same naming of the projects (except for the UI project which becomes part of the main Vendr package), and as such developers should also expect to need to update references to these packages inline with the project names.

Form an Umbraco package perspective, these unfortunately don't currently support a dual-targeted feature, however these is an open issue for adding support for this we hope will be incorporated soon. If this doesn't get implemented however, then we may be required to release individual v8 and v9 Umbraco packages for Vendr.

Questions

I'm sure there will be plenty of questions from people, but we have tried to anticipate a few we think most people will have, but do feel free to get in touch if there is anything specific you would want answers on.

1. How will this work with upgrades?
   Any customer currently eligible to upgrade will be able to upgrade to the new version at no additional cost. Customers are eligible for upgrades if they are within 12 months of a Standard or Standard Upgrade licence purchase, or are paying via one of our subscription plans.
   
   
2. What if I'm not eligible for an upgrade?
   If you are not eligible for an upgrade you can purchase a standard upgrade licence at 600 euro which will entitle you to 12 additional months of upgrades from the date of purchase. Customers on one of our subscription plans do not need to purchase an upgrade license as they are entitled to unlimited upgrades.
   
   
3. Do I need to upgrade for new features?
   Once v2 of Vendr is ready, all new features will be developed against this version. If you are on a v1 version of Vendr, you will need to upgrade through the breaking changes to benefit from new features. 
   
   
4. Will I have to upgrade to Umbraco v9 to use Vendr v2?
   No, v2 of Vendr will be dual targeted and work on both v8 and v9 versions of Umbraco.
   
   
5. When do you plan to start the migration?
   This one we aren't sure about yet and would really love peoples feedback. Would you rather us perform the project structure update asap (we don't need to wait for Umbraco v9 to do this)? Or would your rather us delay it to be as close to the v9 launch as possible?

Conclusion

We have spent a lot of time investigating the various options available to us whilst planning our update and we do not take our decisions lightly, however we do believe that what we have proposed above will give us the best approach to allow us to continue to deliver meaningful features for both our v8 and future v9 customers whilst at the same time ensuring we keep the project as a whole manageable and agile enough to react to future developments.

We would love to hear your feedback, good and bad about our plans so do feel free to get in touch if you have any concerns at all.