Info Gatherer

Project Scope

My husband, Nick West, works at the Information School at the University of Washington. Yesterday, Nick told me that the team he works with could use my help. They needed a desktop application that would run on Windows (specifically, Windows 7). The application would gather some basic system information about the computer, along with information from the user, and then post the data (in JSON format) to a given URL.

Info Gatherer
My Info Gatherer application

The information they wanted was:

  • Machine name
  • Username of logged-in user
  • Local IP address
  • List of running processes
  • Timestamp
  • Name (submitted by user)
  • Email (submitted by user)
  • Comments (submitted by user)

The application itself would be a form with name, email, and comment fields and a submit button for submitting the data (the system information would be hidden from the user).

Implementation

Well, I had never done anything like this before! I opened Visual Studio and created a C# Windows Form Application. I made a skeleton for a class called SystemInfo (which would gather and post the information) and then I started Googling.

SystemInfo Class

SystemInfo Functions:

  • GatherInfo() – Gathers the system information
  • PostInfo() – Posts the system information to the specified URL
  • GetInfoAsJSON() – Helper function for PostInfo() that gathers all of the information and returns it as JSON

I was surprised that getting the system information for GatherInfo() actually wasn’t that difficult. I relied heavily on Google search results for figuring out how to implement PostInfo(). As for getting the information into JSON, I initially tried to write my own parser, which actually worked fine until I tested it with a string that had a “\” in it. My parser wasn’t smart enough to escape characters like that. Whoops! 😛 I didn’t want to have to look up all of the tricks my parser would have to account for (and it was silly of me to write my own anyway), so I ended up using JavaScriptSerializer instead.

Cool, so I had the backend stuff working. Time to work on the form!

Form

Designing a Windows form is pretty straight-forward in Visual Studio. I used the designer to add different controls (labels, text boxes, and buttons) onto the form and then tweak their properties. With the design stuff in place, I went into the form code and added the form’s behavior. The bulk of the logic I needed to add was when the submit button was clicked. I made it so that upon clicking the submit button, the application gathered the system information, posted it to the URL, and then notified the user via pop-up message box whether or not the information was sent successfully.

Configuration file

Adding a configuration file seemed like a must. I didn’t know what text the iSchool Tech Support staff wanted to use in the instructions and messages to the user and I knew that they would want an easy way to change which URL the application posts to. Thus, I added an XML config file that would easily let the Tech Support team change those values.

Setup

I wasn’t sure how to package the application, so that it could be installed with an installation program. Thankfully, Google came to the rescue again! Visual Studio has a built-in setup wizard. 😛 I tweaked a few things, but I was mostly able to just use the default setup package.

Additions and revisions

Phew! I had a finished product! I sent it over to Nick and the Tech Support team for them to play with. They had a few suggestions:

  1. Get rid of the pop-up messages and make it display on the form itself whether or not the information was sent successfully.
  2. Add a feature (which can be enabled or disabled), so that the web server can send a reference # back to the application. This reference # should then be given to the user.
  3. Add a folder called “Help!” to the application directory that contains a shortcut to the application, so they could quickly add a toolbar for the application on the taskbar.

Not so bad! The first change was easy to do. The second change was also simple enough and I added a field to the config file, so they could enable/disable the reference number feature. I didn’t immediately know how to implement the third change, but it just involved a change to the File System in the Setup.

What happens after the information is submitted?

The iSchool web server that received the information sends the information to Request Tracker, the iSchool Tech Support ticket system (which notifies the Tech Support team). When Request Tracker gets the information, it also emails the user to thank him/her for the submission. Nick did this part of the project.

So now what?

The iSchool Tech Support team is going to be playing around with my application over the next week or so. If all goes well, the application could very likely be going on the new lab image (which will be created in a week or two). That means that my application would be on all of the Information School lab computers. The application may also be added to the next faculty/staff image, which would put it on all of the iSchool computers. After that, if the application is working well for the iSchool Tech Support team, they might share it with other schools/departments/etc. in the University of Washington.

As for me, I’m going to open source the application to let other people play around with it. I’m sure I’ll slowly build on the application myself, too. I’m pretty geeked that I was able to figure out how to do this so quickly and that something I made is going to help other people out. 🙂

Update: 2011-12-28

Info Gatherer (now called Desktop Help Request Client) is available on GitHub!