There are lots of gotchas here and there and it does require a pretty reasonable understanding of both legacy and new frameworks.
There are lots of gotchas here and there and it does require a pretty reasonable understanding of both legacy and new frameworks.
I have a bit app: Razor, MVC, EF, custom nuget packages, reflection, very advanced expressions ( linq) and my IoC is Autofac ( .net 4.7.2).
101 projects in one solution.
Have you got any pointers on gotchas? Did a quick attempt ( 1 evening) and got blocked on my nugets+ Autofac.
Also have a look at the MS upgrade/migration guides for .NET. They’re exhaustive and extremely helpful.
I'll have another try later this year probably :p
Yikes. This is in C# I assume? If in VB, I'd run one project through Instant C# and see how many problems you encounter. There are lots of VBisms that are simply not in C# (like statement for one, xml literals, etc...).
Run the simplest project through the `upgrade-assistant` tool. It'll convert it to .NET Core. I saw the sibling post recommend .NET Standard, but if you don't plan on using anything legacy this is more headache than its worth.
But yeah, I hear you on the nuget dependencies. Some of them were never ported to .NET Standard or Core so you are left trying to recompile them manually yourself.
It's c# yeah. But I believe the project is much cleaner and frankly better to understand than all other projects i've encountered for this size. I'm using DDD, so DDD knowledge is a requirement to navigate this in a breeze :) :
- https://snipboard.io/D03VWg.jpg - General overview of the architecture. Small fyi: Connectors => Autogenerated nugets to call the api's
- https://snipboard.io/9M24hB.jpg - Sample of Modules + Presentation layer
- https://snipboard.io/ybp6EH.jpg - Example of Specifications related to catalog ( = products )
- https://snipboard.io/lE9vcK.jpg - How specifications are translated to the infrastructure ( here I'm using EF, so I'm using Expressions a lot), but plain old SQL is also supported. A query is basically a list of AND/OR Specifications where a hierarchy is possible. This would translate to "(QUERY 1 ) AND ((QUERY 2) AND (QUERY 3))" in the Infrastructure layer.
- https://snipboard.io/7rVBpk.jpg - . In general, i have 2 List methods ( one for Paged queries and one not for Paged queries)
Additional fyi: Is V2, so has some legacy code. Uses my own STS. Has 2 gateways ( the ShopGateway that is used to develop new sites and the BackendGateway for the Backend). Enduser frontend is in MVC for SEO purpose, Customer backend is in Angular ( SPA). The basket is a NoSql implementation on top of SQL server.
The enduser frontend supports a hierarchy of themes ( so it's insanely flexible to create variations of pages for other clients).
There are more projects involved outside of this solution, eg. nuget repo's usable accross solutions (JWT, Specifications, ...) and "plugins" for a standalone project that is installed for end-users for syncing local data. So it's +101 projects :)
It's used for eg. https://belgianbrewed.com/
I even hate to suggest it because it's double the work, but I'd convert all your libraries first to .NET Standard 2. And then make sure they will work fine with your .NET Framework 4.x UI projects.
The reason this sucks (I didn't realize it at the time) is that .NET Standard 2 is stuck with C# 7.3. Which means you are missing out on all the C# cool toys. You can't even use .NET Standard 2.1 (and C# 8) because it's not supported by the .NET Framework 4.x.
Then go on to the UI projects. Automated conversion may or may not work. Probably not if it's complex. The middleware won't simply convert, particularly if you had routing, filtering, etc... You may have to create new projects. I was able to copy/paste lots of code (routing for instance) but how it was wired was different.
If you are successful, you can go back and upgrade the library projects from .NET Standard to .NET Core.
Good luck.
Good news is that the nugets are already on it!
Automated conversion didn't go okay enough in a short timeframe ( even with the Microsoft docs).