NOTE: Driver templates and other useful libraries contained within the ASCOM Platform 7 are available in Visual Studio as Extensions. Other libraries not part of the ASCOM Platform are available via NuGet under keyword "ASCOM".
The worst way to undertake driver development is to use the sources for another driver. While it may seem like a shortcut to success, it is almost always a shortcut to troubles, misunderstandings, and propagation of others' mistakes. It can be "the blind leading the blind". Roll your sleeves up, learn what you need to learn, use the tools and templates, and do your best.
The Platform development team has done quite a bit of work to assist driver developers who use .NET languages. .NET is Microsoft's supported development environment, with C# being the recommended choice of language, and Visual Studio 2022 as the Integrated Development Environment. For those who are starting driver development, it is suggested that you use VS2022 and C#, and use the appropriate driver project template we have provided as Viausl Studio Extensions.
As of Platform 7 the templates for DLL type drivers have been removed. Only templates for executable drivers that run as separate programs (so-called "local-servers") are provided. By creating an executable COM driver, you avoid the problem of needing both 32-bit and 64-bit DLLs. An executable driver is "bitness-proof".
Consider writing your driver for Alpaca instead of COM.
None of the build process on Visual Studio needs elevated privileges except when having to initially register the COM object in the Windows registry. For a LocalServer (EXE) driver, once it has been built, you need to do a one-off run in an Admin shell
LocalServer.exe /regserver
After that, there is no need to re-register it again. Another reason to make executable drivers instead of DLL ones.
Most drivers will need to save persistent data (e.g. COM port selection). It's highly recommended that you use the DriverHelper.Profile object for this. It has a very simple interface and guarantees that you will get private storage for your persistent data items. It uses an area of the registry set aside for ASCOM drivers. A browser, the Profile Explorer, is provided in the Platform to help diagnose ASCOM registration issues and to allow inspection and editing of driver-specific data.
It is possible that the layout of data in the registry will change due to future opperating system restrictions. This already happened twice(!) for Vista and Windows 7. Either way, if you write directly to the registry you're asking for trouble. Drivers which used the Profile object were unaffected by those changes to the Platform. On the other hand, if you choose to write your own private persistence storage code (e.g. to an XML file) that's fine too. Just be aware that your persistent data will not show (and be editable) in the ASCOM Profile Explorer, which is a useful troubleshooting tool.
All ASCOM interfaces include a SetupDialog() member. This is intended to display a modal dialog that provides access to device-specific things like COM port selection and controls for device-specific features. Keep in mind that many client programs expect a "perfect" device looking into the driver, and will use the device to support observing. Features like PEC, pointing/tracking models, backlash compensation, etc. that aren't exposed through the standard interface belong in the setup dialog.
This is a frequent source of confusion and frustration for driver developers, as they want to expose the "value added" features of their device where the driver interface doesn't support those features. Try to resist the temptation to have your driver open a "permanent" modeless window with a bunch of doodads like position or coordinate displays, switches, buttons, etc. The client sofware users will see these windows appear when they connect to the device, and they will think the window is part of the client program. This generates pain for client software developers who get asked for support. It also allows users to change things during normal usage, risking obscure problems and confusion.
Besides registering your driver as a Windows Object (COM), it also must be registered for ASCOM in order for it to appear in Chooser. At a minimum, your installer needs do this. If you use C#.NET or VisualBasic.NET and the templates included with the Platform 2008, this issue is handled in the driver by the template code. Otherwise, if you use the Inno Setup tools included with the Platform Developer Components, it will be done for you. Otherwise, you'll need call the Profile.Register() method during install and the Profile.Unregister() method during uninstall. It's up to you to figure out how to do this with your installer tools. Be sure to remove the driver's ASCOM Chooser info when the driver is uninstalled.
An executable (local-server) driver can expose multiple interfaces (for example Telescope and Focuser for a mount that has both pointing and focuser controls). Another reason to abandon DLL type drivers.