Another VSI package for you, this time handling common win forms settings.

It provides auto upgrade code for new versions of your application, window size and position loading and saving.
It handles the initial loading of an app as well as closing whilst minimized/maximized.

I'd recommend installing them into a Settings folder under your My Documents\Visual Studio 2005\Code Snippets\Visual Basic\My Code Snippets folder.

You can download the package from my Visual Studio 2005 Tools downloads area.

This isn't something I came up with - I'm not taking credit for it.  I just found it on the net a long time ago and a colleague asked me about it so I thought I'd put it here for future reference.

With VS2005/.net 2 you get the ever so useful my.settings stuff.  This is fine except it's version specific.  When you release a new version of your app it creates a whole new settings file, ignoring the previous one for the old version.

To overcome this put in a new boolean setting, I call mine CallUpgrade, and set it's default value to True.

Then in your form load/get settings sub do the following;

        If My.Settings.CallUpgrade Then
            My.Settings.Upgrade()
            My.Settings.CallUpgrade = False
        End If

Now every time your app load it will look at your current CallUpgrade value, if it's the first time that version's been run it will be true and so the specific My.Settings Upgrade method will run which looks for a previous version and ports the setting values across.  Then setting the CallUpgrade flag to false for future loads to not waste time trying to upgrade the settings.

Simple, a little cludgy on Microsoft's part not to have a more clear solution to it but this does the job.

One thing that I've always understood, but always been frustrated by is corporate firewalls where they block both inbound and outbound ports.

Yeah, I know the reasons, stopping unauthorised software having freedom to do what it pleases and that's a good thing.. but sometimes things go a little too far for convenience.  Take incoming email for example, good old port 110 is most often used and is one of the first to be blocked by most sys admin's.  Again, sort of understandable but annoying if you want to check your own email account from work, you have to use some usually awful webmail system and keep refreshing it all the time.

Recently I've been doing a lot of work with web services and this got me thinking, you can do pretty much anything on port 80, why not just write services that do all that naughty stuff and host that on the outside world, then write small app's sitting inside your organisations firewall that just talk to the service.. and it works!

I wrote a small web service that had one method, GetMessageCount which took a mailserver, port, username and password as parameters and returned the number of messages in that inbox.  Simple stuff when you have a pop3 library to hand.

Then I wrote a small tray application that called this web service every 10 minutes with appropriate mailbox details and displayed a message balloon if the number of mail messages increased over previous checks, therefore prompting me to login to my webmail and take action.

So, if you want simple status reports, or perhaps even more complex systems, as long as you've got some programming interface to it why not wrap it up in a service and write yourself some desktop app's to interact with it.  Until your company implements content filtering as well as port filtering you'll be happy!