Any of us that creates software on a day-to-day basis, that’s actually used by someone other than yourself, has undoubtedly had to answer technical support questions about your software and/or troubleshoot why it’s not working. In a lot of cases, you may have a dedicated support team that interacts directly with your customer base and they only contact you if they come across something they can’t resolve or explain. Over time, the support teams tend to become very efficient at resolving application-specific issues regarding setup and configuration. However, when an application is first released, the process isn’t so straight-forward and you may have to field a lot of questions.
Now, don’t get me wrong, I’m more than happy to answer any questions I can about the software that I produce. However, I’m also interested in maximizing everyone’s time (mine, the technical support staff’s, as well as the end-user’s). That is why I decided to create NDiagnostics. The purpose of NDiagnostics is to allow for the easy creation of a self-diagnostics utility customized for a specific application. For example, if your application requires certain files and/or folders to be present, a specific version of the .NET Framework, and possibly access to a SQL Server database, then you can create a custom configuration file that can quickly and easily scan a user’s machine for compliance. Here’s a sample screen shot of what NDiagnostics might look like after scanning a user’s workstation:
In this example, the SQL Server Service’s Startup Type was not set to Automatic as expected. However, you can quickly ascertain that the required .NET Frameworks are installed, the SQL Server service is running, Visual Studio is running (yet another strange requirement), my blog is available (yeah!), and the application’s database is accessible.
This isn’t necessarily a real-world example but it does demonstrate how easy it can make troubleshooting certain tasks. It only took a few seconds for the above tasks to run – it would have taken several minutes to verify these tasks manually (possibly hours if the technical support staff had to determine what to verify to begin with).
NDiagnostics is completely configurable via an XML-based configuration file. The configuration file defines the groups of diagnostic tasks to be run as well as the order of the tasks. NDiagnostics currently ships with the following tasks:
- File Task – checks for the existence of a specific file and can also (optionally) check the version number.
- Folder Task – checks for the existence of a specific folder.
- NETFX Task – checks for a specific version of the .NET Framework.
- Process Task – determines whether a specific process is running.
- Registry Task – allows you to verify registry settings.
- SQL Server Task – checks for connection to specified database; optionally check for table existence and/or query result.
- URL Task – determines whether a specific URL is available (can verify web page or web service).
- Windows Service Task – determines whether or not a specific Windows Service is installed, and optionally, the current status (e.g. running, stopped, etc.).
Being that this is the first release the set of tasks is somewhat limited. There are several new tasks currently in the works that will be made available in future releases. Also, the project just went “live” tonight so I’m still getting the on-line documentation up to speed.
So, if you have a need for a quick-n-easy diagnostics tool, give NDiagnostics a look. Please provide any feedback as I would like to make this utility as useful, friendly, and simple as possible. If you have any suggestions for new tasks, please post a comment here or leave feedback at the NDiagnostics site. Also, the source code is fully available so you can customize this application to your liking.
Time to resurrect this year-old post, I think.
I’ve just found the reference to this project, and I think it is going to be a real time saver in my organisation. I do have a couple of questions, though…
1) Would it be possible to add support for a config-definable root path for the fileTask elements. Quite often, we will develop and deploy locally in one path (e.g. $projectfolder/bin/debug) on the dev machines, but to a “real” location on system test / live boxes. It would be much easier to change a global config option than find/replace on a potentially large number of file elements.
2) Is there any kind of automated tool to create a configuration file for a folder full of files? I’m looking into my own config creation utility, but it would be neat if such a thing already exists. :)
Anyway, thanks for a very handy tool.
Marc,
#1 (configurable root paths) shouldn’t be too big of an issue. I should be able to get that feature in within the near future.
#2 – there is currently no tool to create a configuration file although it is something I have thought about. If you have a desire to create a utility, and would like to contribute to this project, let me know and I can set you up in CodePlex.
Jeff,
I’m more than happy to start looking at a configuration utility, although I don’t have access to VS2008 ( :( ), so any solution I create would have to be in 2005 format.
If you can, please drop me a line via the contact form on my out-of-date blog at http://chillijam.wordpress.com/get-in-touch/ Should be easier to get the ball rolling from there. :)
hi mister,
Ndiagnostics dies ??? it’s a pity !!!
i’m sad :'(
greetings