It took a bit longer than I would have wanted, but now version 4 is out. So why the new version number? When version 3 was launched there was a change to the object model so that it would closely mirror the underlying JavaScript API (Google's Maps API). Since the release of version 3.0 the control has undergone some
tremendous changes as Google has continued to develop their service,
new overlay types, new geocoding services, etc. So for that reason
alone a new version seemed justified. But as with all version
numbering, it's down to a subjective decision as to what constitutes a
new version. The reason that this release is a new version is because
of the ability to define maps using only markup. This is a major change
in the way maps are set up on the page, so it felt right to call it a
new version.
Originally the control was designed to make it intuitive to use the ASP.NET control as you could transfer all your existing knowledge from working with the JavaScript API. At least that was the idea.
Things don't always work the way you want them to. After more that 6000 downloads, and hundreds over developers using it on their sites, you realize that they do things differently, and they have different expectations for how the control should respond. One thing that became obvious was that people wanted the control to work according to their ASP.NET habits, the ASP.NET habits should not have to yield to clean AJAX using JavaScript. Being able to define more map features using markup fits in nicely with
the way that ASP.NET developers seem to want to use the control - and
let's face it, if it doesn't appeal to ASP.NET developers, who's going
to use it :-)
There are a lot of features that you only want to define once for your application, no matter what happens. For example, you don't want to have to use if(!Page.IsPostBack){ /* set up my map controls and icons */ } in the code behind. The control should take care of that for you. Now, if you define your controls and icons in the markup you don't need to worry about them. Simply use them in your code behind, when you create your overlays.
For static maps it makes even more sense. They are intended to be more or less static, so why not define them directly on the page? On static maps you can define how your map looks and which overlays directly in the markup (you can as well with normal maps, but there you probably want a little more control over the overlays' behavior).
I'm not going to put code examples here. I posted some when the beta was announced - and there is more in the documentation.
Another thing that has been a major complaint is how to get started. As mentioned above, the idea that you would transfer your knowledge from the base API, has been shown to be wrong. When defining maps using markup Intellisense shows you which options are relevant for your current action. This is what you would expect when setting up your ASP.NET page, so of course the control should work in the same way. Hopefully this will also give you some hint about which classes to use for different actions.
A lot of people have asked for specific instructions on how to create their web application. The documentation has been updated with a lot of new examples and more in-depth explanations. If you have a specific problem, do feel free to ask in the forum or send a private message. But remember that if it takes time and effort for you to do something, it will also take time and effort for someone else to do it. So please contribute to the project if you expect to get anything out of it (money is nice, but answers to other people's questions and examples are equally appreciated).
As usual you can download the control here and the source code here, or from svn://svn.reimers.dk