I realize I made a bad design decision for using this method. (previous post)

I did not want the application constantly polling for a new version so I just check once before I start up the app. Unfortunately, the process of checking (not even downloading) takes about 8 seconds (on my fast client machine). So everytime they start the app they have to wait. Which is why you want it to happen in the background. Maybe the polling isn’t so bad after all.

I don’t like the options. I would like to find a happy medium. But for now because I have spent so much time trying to get this worked out (was it even worth it) and my client needs me to move on to other projects, I’m going to have to leave it. So all in all I’m very unhappy that I went this route. I wish I had known enough about the process to realize this problem in advance.

I never really discussed this part of my design with Chris Kinsman when he offered to work out the other issue I was having. I probably should have. He knows this stuff better than almost anyone.

The people who are in-house hitting the web server locally are going to be the big losers with this solution. The people who are using this application over the web (the back end is a web service) will definitely benefit since we couldn’t figure out how to push out updates to them. So I may end up modifying this again to handle local connections differently.

Posted from BLInk!

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!