Question

I have an windows application (WPF) in which we are running on each login, however when the user first logs into a new PC the application will need to do some specific tasks, but only on the users first login and never on subsequent times.

Is there a way in .Net 3.5 to query wether the user has logged in before (ie some kind of login count)?

Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.

We use redirected folders so the user may have already logged into a PC on our network these special events should only occur when the user hasnt logged in onto the PC and Windows has had to create a new profile for the user on the PC.

If I am not clearly explaining what I am seeking, please dont hesiate in letting me know.

Matt

Answer 1

Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.

I’d recommend going with this option. Don’t try to detect it, just create your own state on first run.

I suggest this, not because it is technically impossible to achieve the functionality you describe, but because it is a better user experience. It provides an easy way to re-do the action without having to recreate the user.

… a txt file in the users registry …

I’m not sure what this means. You can create text files under the user’s profile directory, and you can insert string values in the registry (but not files of any sort).

As for the particular mechanism, I suggest you consider:

• An App.Config value. Clearing out the value is easier to support or batch-script than a registry value, and makes the user less scared that their machine will explode if you have to tell them to edit the settings. Users are scared of the registry.
• A sentinel text file under the user profile directory. Wiping out the file is super-easy to support and batch-script. Instead of editing a text file, they can just delete one. But this makes it so you have multiple config mechanisms, so multiple points of failure. I’d only do this if I were using the App.Config for additional settings in the program and thought the user wouldn’t be technical enough to hand edit it.
• The windows registry. Remote registry access might be easier than remote file access, if you’re having to do remote troubleshooting. It also might be easier to mess with via group policy, in case this is an intranet app and you need to force a re-run on all machines in your org.

I’d carefully consider my options and which is most likely to ease support (be understandable by my users) before committing to one. I’d also consider the remote-troubleshooting/remote reset scenario.