Working with MSCRM and from my background I have typically always been a web programmer as have my colleagues. This is essential in the MSCRM world if you want to be able to customize anything from form scripts to placing your own page that does crazy things right into the middle of the MSCRM GUI.
However, when presented with the task of needing to mass update data I have found that there are sometimes better ways than a web page. I have had minimal experience with application programming and programming an executable used to be a mystery to me.
A need presented itself for one of my clients where a procedure was needed to be rerun on a scheduled basis. Most of my previous procedures of this type were custom web pages with a "Go" button that ran all of my code. I quickly realized that I couldn't schedule a pressing of my "Go" button and I needed another solution. An executable was the solution.
I was scared that I was going to have to spend the better part of a week fighting and learning new calls and commands but amazingly enough, the majority of my code (the calls to the MSCRM API's) was all the same. For me, the learning curve into non-web programming came relatively quickly and there were a lot of benefits. There are benefits to both worlds so don't think that I've gone away from mass updating via web pages because that's not the case. Here are some pro's and con's that I have run into when developing a solution for a web based or console based solution.
Web Based Solution Pro's: If you are already a web developer then you have all the skills required. Web pages can also be used externally very easily where console applications are a bit more difficult. One other advantage to web pages is that they are great to if you want your end users to access them and use them. Things like, update addresses for contacts related to a given account, or moving records from a sales rep's territory to a new territory owner are great for end user usage.
Con's: You have to set up the web page. If you don't build security around it everyone can see it and possibly use it. It cannot be scheduled, it must be run manually.
Console Based Solution Pro's: Other than the coding, there is no additional set up, you just double click the executable or run it from a command prompt and away it goes. You can set up Scheduled Tasks that can run your code whenever you tell it to be run. Nightly, hourly, weekly, yearly, whatever. Also, if you build your code dynamically enough you can take your code from one installation to another and have it run just the same (authentication would have to be set up to be entered when run). Your code is compiled and no one can read your code unless you give it to them. Web pages have the ability to "View Source" and that might show off more than you want people to see.
Con's: Running externally requires that credentials be hard coded into your code. Most end users don't like running executables because they think it will install something on their machine and they don't understand what the code is doing. Black console screens (where you type in commands) scare end users. They have this mental block where if it's not in a GUI they don't understand it and would prefer not to have anything to do with it so that they don't break the system or their computer.
Well there you have it. Decide for yourself, each implementation is different so each usage can be very specific. I have a consultant's point of view where I have to be ready to do something for one client and then turn around and do something extremely similar but with minor differences for someone else and these differences between web based and console based applications can make all the difference.
Happy coding!
David Fronk
Dynamic Methods Inc.
