Creating a separate Driver and Hosting App is not required, but doing so gives you the greatest deployment flexibility. By developing a separate Driver assembly, you can reference it from different project types on different platforms, especially if you target either .NET Standard 2.0. Then you can just create a specific simple Hosting App for each deployment scenario without recompiling your driver. If you only have a single deployment target in mind, you can collapse these two projects into a single Hosting App that contains both the Driver code and the runtime host functionality, whether that be a Console Application, Windows Service, etc.

• If your platform is Windows and you're required to support the full .NET Framework 4.0 or 4.5, your Driver assembly must target the full .NET Framework. Typically this will be .NET 4.0 for wider compatibility.
• If you choose to deploy the Driver to Linux or other platforms, or if you want to create a Driver assembly that can be used on all platforms including Windows with .NET Framework 4.6.1+, then target the .NET Standard 2.0.
• However, if you are required to use a 3rd party assembly for interaction with a data source or API, the target framework will be dependent upon the framework that this assembly supports, and may determine other limitations in deployment.

Using the .NET Standard 2.0 specification, and .NET Core, you can build communications drivers for OAS that run on Windows, Linux, Mac, Android, and iOS. You can even deploy a driver to run on a Raspberry Pi running the Raspbian OS. Read more about UDI Platform Support for specific OS versions and requirements.