There is a lot of information here and in the pages on the list to the left. This information can save you time and frustration during your development. Please invest some time to check it out before getting heavily into your development.
If you're new to ASCOM, and you're an application developer (as opposed to a driver developer), check out the Getting Started information. which includes an excellent video showing the development of a complete program for controlling any telescope using Visual Studio using Visual Basic .NET. Then, if you are developing your application in one of the Microsoft .NET languages, learn about the ASCOM .NET Client Toolkit.
Most of the driver developer tools are contained within the ASCOM Platform Developer Components. Driver developers are strongly encouraged to use those tools. This is particularly true for driver developers who write in C# or VB.NET. The Developer Components contain templates for all driver types in both C# and VB.NET. Using these templates will save you heaps of effort and troubles.
You may benefit from watching Tom How's excellent video showing how to develop a driver for a telescope control system using the popular Arduino microcontroller kit.
Before embarking on driver development, you should have the ASCOM Platform Developer Components installed on your system. Driver templates, most of the developer documentation, and the installer generator are included in the Developer Components installation. The developer components are provided as a separate download from the Platform itself.
See Conformance Testing. Once you have your driver working, it's very important to test it with the Driver Conformance Checker tool. This tool will exercise your driver and the device it handles, checking for common programming errors.
The ASCOM Platform includes simulators for each of the devices covered by an ASCOM standard. These simulators provide a convenient tool for application software developers to test their programs with known good drivers under controlled conditions. The simulators also serve driver developers as reference implementations of the driver standards. If there is a question about the behavior of a property or method, the behavior of the appropriate simulator serves as the reference.
The interface specifications aren't the full story! There are some design principles that, if adhered-to, will maximize the chances that your driver will operate properly with a variety of client software. The links on the left lead to information on each of these design principles.
It probably seems unprofessional to start this section with what not to do, but we're just trying to save you time and pain. Over the last 12+ years we've seen the same mistakes repeated by driver developers enough times to rate being listed here. Hopefully a word to the wise is enough.