[RESOLVED] Run Key Copies EXE to System32

[RaleTheBlade]

I am attempting to make an application run on startup for every user on the local machine (pretty easy, I know) however if I place an entry into the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key, it starts the application fine but "copies" the executable and runs it in the Windows\system32 folder which causes problems with licensing and the like. I am using the full path to the executable, so its not relative to the system32 folder...
Whats going on here? Why doesn't it run it from the executable folder where it is located?

[Arjay]

What do you mean it 'copies'? Physically copies? Or the current directory within the program has been set to \system32? If the latter, and you are using GetCurrentDirectory within your code, I would suggess that you don't rely on GetCurrentDirectory; instead use GetModuleFileName to locate the full path of your executable.

[RaleTheBlade]

Well... so far your right Arjay. The working directory gets changed whenever you use a registry entry in the HKLM\...\Run key to start the application and the application is acting like its running in Windows\system32. Now, how to go about fixing this. Is there anything you can do to prevent the directory from being changed? Im only seeing two options out of this one:

1) Change the directory back to the executable directory when the application is started by using Directory.SetCurrentDirectory()

2) Change all of my paths that reference items in the .exe directory to have absolute paths.

Any other ideas? Thanks for the help :)

[Arjay]

Sorry about the previous Win32 answers - I thought we were in a different forum.

The GetDirectory approach doesn't work too well because this path can be changed at any time. It can be changed by a 3rd party component or by the system, so it just isn't reliable. The other way it's changed is at program startup as you have found out.

What you want to use is the Assembly.GetEntryAssembly method. This will always point to the current [physical] location of the process exe.

Don't use absolute paths. Sure, it may work okay today, if you need to move the exe, or run it on another machine, or... too fragile.

[RaleTheBlade]

I understand :) And by absolute path I meant doing something like:


// This is just an example, not real code
string exePath = Assembly.GetEntryAssembly().Location;
string exeFolder = Path.GetDirectoryName(exePath);
string exeConfigPath = exeFolder + "\\myapp.config";


But that requires reflection. I know that Directory.GetCurrentDirectory() is unreliable so I tend to avoid its use. However, this whole startup thing with the registry key was unexpected so now its time to fix it. Ill just have to reset the current working directory on startup and go through and find all of my relative paths (I know... big no no) and fix them as well.

Thanks for the help :wave:

EDIT: Oh, and i like Win32... if I had it my way I would do everything in Win32. Gives you so much more power and I know what the heck is going on at a much lower level. I always say "Its my memory! Let ME clean it up!", hahaha

[dglienna]

Look into Click Once deployment. You can have an app that doesn't get installed on the client, which runs ONLY when the source is available

[Arjay]

But that requires reflection. Not really. It requires functionality that is located within the reflection assembly. Why is reflection an issue?

[RaleTheBlade]

Look into Click Once deployment. You can have an app that doesn't get installed on the client, which runs ONLY when the source is available

We have looked into ClickOnce but we needed an installer with more options for configuration at install and uninstall time so we went ahead and used the Windows Installer.


Not really. It requires functionality that is located within the reflection assembly. Why is reflection an issue?


I just tend to avoid it if I can... you know, performance hit and the like. But its not really an issue in this case so Im going to go ahead and use it :)

[Arjay]

I just tend to avoid it if I can... you know, performance hit and the like. But its not really an issue in this case so Im going to go ahead and use it :)Yeah, I doubt that particular function is doing any real reflecting. At any rate, if you are concerned about performance, just call the method once at the start of your program and save the result.

Something like:

public static string GetAppFolder( )
{
static string appFolder = String.Empty;

if( String.IsNullOrEmpty( appFolder ) )
{
appFolder = Path.GetDirectoryName( Assembly.GetEntryAssembly( ).Location );
}

return appFolder;
}

[RaleTheBlade]

Yeah, I doubt that particular function is doing any real reflecting. At any rate, if you are concerned about performance, just call the method once at the start of your program and save the result.

Something like:

public static string GetAppFolder( )
{
static string appFolder = String.Empty;

if( String.IsNullOrEmpty( appFolder ) )
{
appFolder = Path.GetDirectoryName( Assembly.GetEntryAssembly( ).Location );
}

return appFolder;
}

Sorry Arjay but I think your getting your C++ and C# lines crossed again :) I don't believe that declaring a static local variable in C# is legal, although I do know where you are going with the idea. I will just get the executable directory at startup, save it "globally" somehow, and use it when I need to. I believe this problem is toast, Im marking this thread resolved :thumb: Thanks for the help

[Arjay]

Sorry Arjay but I think your getting your C++ and C# lines crossed againYep, so just make the variable a private member of the class that contains the method.