Refactoring after open-sourcing (HAST-303)

[Zoltán Lehóczky]

After open-sourcing, it's time for some refactoring. E.g.:

• Do we actually need the Abstractions projects?
• Do we need IDeviceDriver and IDeviceManifestProvider separately?
• MemberSuitabilityChecker can be moved?

Jira issue

[Zoltán Lehóczky]

Perhaps something you'd be interested in, once we finish the open-sourcing, @DAud-IcI?

[Sára El-Saig]

In my opinion:

• Do we actually need the Abstractions projects?
  • Do we plan to publish Hastlayer to NuGet? If yes, then there isn't much point to them.
• Do we need IDeviceDriver and IDeviceManifestProvider separately?
  • I don't think we need both. I'd prefer to keep the name IDeviceDriver because it's shorter.
• MemberSuitabilityChecker can be moved?
  • If you mean to move it into Hast.Communication, I see that's currently not available from inside Hast.Transformer where this service is used. I don't think adding Hast.Communication to Hast.Transformer would cause a problem, but why not keep it where it's used?

Other Ideas:

• Clean up directory structure. In the file system they're still called Hast,Abstractions and Hast.Core. Also move Hastlayer-Hardware-Framework---Vitis into Hardware Frameworks/Vitis to make it cleaner in case we need to reference other frameworks in the future.
• Consider replacing the IDependency stuff with static dependency building like in ASP.Net Core. Since Hastlayer doesn't have ties to O1 any more, it's probably confusing to other developers. Also since I've become more familiar with OC and ASP.Net Core it looks incredibly cursed. Maybe that way we won't have to worry about the GetHastLibraries() stuff either because we discover the assemblies the same way ASP.Net Core does? (I don't know how they do it, but looking that up has to be easier than inventing something on our own.)

[Zoltán Lehóczky]

1. Yes, we will publish Hastlayer on NuGet, see #35. Also see that for some notes related to refactoring. I don't see much point in keeping the Abstractions projects either, apart from the Orchard-style "let's keep interfaces in separate projects" approach, but I don't think this has much of a use here.
2. IDeviceDriver sounds good.
3. OK, let's keep MemberSuitabilityChecker, then.
4. Having subfolders for Abstractions (if we keep it) and Core is fine, to have some structure, even without the flavor thing, but we can also put these projects into the root. Also good idea on the framework folder.
5. I think the assembly discovery with module Startup classes is rather an Orchard thing than an ASP.NET Core one, but I'm fine with having manual dependency registration too. Note that why we didn't do that at the time of the .NET Framework -> .NET Core migration was because we have a huge number of dependencies, so we'd need to move all of those marker interface-based registrations to explicit one.

[Sára El-Saig]

Having subfolders for Abstractions (if we keep it) and Core is fine

I meant that the actual folder is called "Hast,Abstractions" instead of just "Abstractions" (without the "Hast.") in the solution view. This should be harmonized, and imo just Abstractions is better because then the projects in root are alphabetically separated from the directories. Same for Hast.Core vs just Core.

[Zoltán Lehóczky]

Sounds good. But then again, we can remove this level too, since we don't have that many projects if we won't have Abstractions (and in the near future people will just use Hastlayer from NuGet, so the folder structure will only be interesting to us and contributors).

[Sára El-Saig]

Do we still need the SharedAssemblyInfo.cs? We don't do that in any other of our projects and I wonder if it will even work with the NuGet package generation workflow.

[Zoltán Lehóczky]

We need to centralize that config in some way. It can also be in the Directory.Build.props file, that might be slightly better (since no inclusion is necessary in each project). While the version config won't be needed once we do #35, the rest will be still.