[.net] Install Process, and access to the Registry

Started by
9 comments, last by TheTroll 14 years, 1 month ago
Hello, perhaps I should be asking this in the MSDN forums, but i thought i'd give it a go here first. I've got a Visual Studio Setup project, with some custom actions, one of these custom actions simply tries to set a registry key value in the HKEY_CURRENT_USER section after install...and then it executes an exe file. My code would look something similar to this

void InstallerClass_Committed(object sender, InstallEventArgs e)
{
     RegistryUtility.SaveRegistryValue("CurrentVersion", 1.00);
     Process.Start("myEXE.exe");
}

My RegistryUtility.SaveRegistryValue is something like this..

        public static void SaveRegistryValue(string registryKey, string value)
        {
            
            RegistryKey masterKey = Registry.CurrentUser.CreateSubKey("SOFTWARE\\MySoftware\\Properties");
            if (masterKey == null)
            {
                //i'm not sure how this happens..so ima leave it blank
                
            }
            else
            {
                try
                {
                    masterKey.SetValue(registryKey, value);
                }
                catch (Exception ex)
                {
                    //error handling not relevant to this post
                }
                finally
                {
                    masterKey.Close();
                }
            }
        }

Then when myEXE.exe loads, it also saves some registry values. The problem is, that when it saves these registry values...it's saving them under the Default Profile (HKEY_USER/.DEFAULT)...it does this both when I save registry values from the installer, and when it launches myEXE.exe for the first time. Everytime I launch myEXE.exe after that, it will use the intended HKEY_CURRENT_USER registry keys (it works as intended if I launch myEXE.exe, as in not the installer launching it). This is a problem because I need to be able to read what I wrote during the installer, and the first time the application is run ect. Any ideas on what I should do? I'm not a pro with installers, I know they get some kind of elevated privileges or run under some different settings or something, but is there a way I can still get access to the current users registry keys? I tried launching myEXE with some ProcessStartInfo filled out like this

 ProcessStartInfo info = new ProcessStartInfo();
 info.FileName = "myEXE.exe";
 info.LoadUserProfile = true; //thought maybe this would do it for at least the myEXE.exe part..but nope
 Process.Start(info);   

but that did nothing. I'm a bit stuck here, and any pointers would be great. Thanks
Advertisement
First of all why are you writing stuff to the registry?

Second, why in the world are you writing version information to the registry?

Okay, so why did I get all in a huff? Well because the registry is not a data storage file for you to toss things. People often do this and the registry gets bloated and starts taking up extra resources. Also people almost never clean up the registry when they do the uninstall so the data never goes away.

So what do you do?

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

Put a config file there.

The advantages is that you can expand your files as you see fit. There is no need for elevated permissions and if you need a default value you can put it in the default user.

theTroll
....

I greatly simplified my example for clarity, as I didn't want to give an example of something that didn't make sense to anybody. Believe it or not there is more to the application than reading and writing registry keys and using the registry as personal data storage spot. It's also not really named "myEXE.exe".

I use the local application directory for my configuration files.

I'm writing the installer/uninstaller at the same time as my application to be sure everything is cleaned up fine.

I probably could waste a lot more time and re-write the applications differently so it didn't use the registry at all...but..why? Couldn't you argue the same dumb argument that I wouldn't delete the application files in the local app directory and there'd be junk there always?

Also..you may have mis-understood part of my post. I don't need elevated permissions...I was just stating that when I run the installer (as any installer I believe)...they're given, I thought this had to be tied to the reason it's not putting the keys in HKCU.

I have no idea why I have to explain stuff like this to ask a fairly straight forward question.
You might need to write to HKEY Local machine/software durin ginstall and then copy to the HKEY/current user when running the app.

The reason that the registry is different then your app directory is that the Registry Hive is loaded all the time, your app data is only loaded when your application is run. Registry Bloat is a major issue on many machines.

Now if you really really want to do this, you HKLM/Software/YourApp. The problem is off course you need admin access to write to HKLM.

I would still suggest using the App Directory. If you are already using config files then the rewrite might not be so bad. No one like going back and rewriting stuff but often we learn that there are better ways and some times we need to suck it up and just rewrite it.

theTroll
I'll mess around with something like that. Admin access is not a problem as the installer is always givin admin access. The problem now is that when I launch my application from the installer...it is also launched under some other profile, the ProcessStartInfo.LoadUserProfile seems to have no effect, I'll have to read up on the docs for that.

Switching the values I have in the registry to some type of config file just feels like I'd be going backwards. It's a pain to modify the values, add new ones, remove old ones. These aren't settings I want the general folk to change either (granted if someone is that desired to change them they can figure it out). The registry gives me some type of isolation, and is a hell of a lot easier to manage/deal with, its also probably faster.

I'm not making adobe photoshop here, I have very few values that need to be held in the registry, since the targeted platform is .net and wpf...i don't think these few entries will be taxing on ANY computer.

So yeah, I'm not convinced that rewriting a bunch to specifically NOT use the registry is a good idea at all...more like a waste of time for a worse solution.

Are there any other reasons you seem to feel so strongly against using the registry other than some possible registry bloat...the only problem I see is if I don't clean up after my application, and leave hanging keys...even then..compared to other applications, this would be nothing.
Quote:Original post by ArchGthe only problem I see is if I don't clean up after my application, and leave hanging keys...even then..compared to other applications, this would be nothing.


I've got nothing against your use of the registry but I should note that I'm sure almost every application developer that doesn't clean up after their app feels this way. The little bits build up.

Flimflam hit the nail on the head. "Oh, it is only a couple of keys, for my app, shouldn't be a problem." In the end the registry is a mess.

And I must be confused, because by what you are saying is there would be A LOT of work to redo this code. I just can't see how reading and writing the values to a file (even encrypted) would be more then about 45 minutes of work.

Registry reads are often slower then a simple file read. Write are most often slower.

theTroll
so there is only problem is if you don't clean up? Which also seems pretty easy to do, and to test.

Can anyone show me how to run a process using the local user profile from an installer? This also caused other problems in the past when using code like
Enviorment.GetFolderPath(SpecialFolder.Desktop);

^^returns the wrong path on XP machines if the app is run from the installer. Had to switch it to
Enviorment.GetFolderPath(SpecialFolder.LogicalDesktop);

(or something like that)

thanks.
If I may I'm just going to kinda re-explain the problem, it seems the solution is to handle this kinda stuff on the application 'first-run'. The problem is..

-Windows Installer requests admin access, so the admin profile is loaded, which no longer has anything to do with the current user.

-I launch my application after the install is finished, but since we're using the admin profile, the application is also launched under the admin profile, and not the current user.

-------

If i'm incorrect in any of the above, please correct me.

Although I may give into the theTrolls' demands and rewrite everything with no registry contact, I'd still like to see a solution, or how this is normally handled.

This topic is closed to new replies.

Advertisement