I have a general purpose Utility dll file used in my WPF program. The first thing my program does is check for an updated dll file and copies it to the executing directory – all without referencing any methods or properties from the dll.
When I compile and run the program from inside Visual Studio (v10) everything works as expected. The program starts, checks the dll file, copies if needed and then proceeds to use the assembly.
If I run the compiled .exe file from Windows Explorer it seems the first thing it does is load the Util.dll assembly. This locks the file and will not allow me to update it.
Does anyone have some insight on why the program would opperate differently in Visual Studio vs the .exe file? Any thoughts on tracing what is causing the assembly to load when running the .exe file?
Here is a code snippet of the program startup:
void AppLoad(object sender, StartupEventArgs e)
{
//Used to see what assemblies are loaded.
System.Text.StringBuilder sb = new System.Text.StringBuilder();
foreach (var item in AppDomain.CurrentDomain.GetAssemblies())
{
sb.AppendLine(item.FullName.ToString());
}
System.IO.File.WriteAllText(AppDomain.CurrentDomain.BaseDirectory + "test.txt", sb.ToString());
//Check for the latest Util dll.
if (!UpdateUtil())
{
//Shutdown.
Application.Current.Shutdown();
return;
}
//Start the main window.
MainWindow m = new MainWindow();
m.Show();
}
bool UpdateUtil()
{
//Verify network path.
if (!Directory.Exists(_componentPath))
{
MessageBox.Show("The program encountered an error.\r\rPlease contact your Program Administrator with the following information:\r\r" +
"Program Name - Genesis Admin\r\r" +
"Error Message - Network Component path not found.", "Error", MessageBoxButton.OK, MessageBoxImage.Error);
return false;
}
//Verify file existance.
string sourceFileName = _componentPath + "Util.dll";
if (!File.Exists(sourceFileName))
{
MessageBox.Show("The program encountered an error.\r\rPlease contact your Program Administrator with the following information:\r\r" +
"Program Name - Genesis Admin\r\r" +
"Error Message - Network Util file not found.", "Error", MessageBoxButton.OK, MessageBoxImage.Error);
return false;
}
string destFileName = AppDomain.CurrentDomain.BaseDirectory + "Util.dll";
if (!File.Exists(destFileName) || File.GetLastWriteTime(sourceFileName) > File.GetLastWriteTime(destFileName))
File.Copy(sourceFileName, destFileName, true);
return true;
}
This is in general a risky thing to do, assemblies get loaded by the just-in-time compiler when it needs to generate the machine code for a method. What you are probably not counting on is code that gets inlined, an important optimization that’s enabled in the release build. That optimization is off when you run with the debugger.
It isn’t obvious in your snippet which type might be loaded from “util.dll”. But be sure to restructure your code so that all types that are from util.dll are in separate methods far removed from UpdateUtil() call. Suppress inlining with the [MethodImpl(MethodImplOptions.NoInlining)] attribute on the method.
By far the best way to do it is with a little bootstrapper .exe file that does the test and then starts your main .exe. But do keep in mind that you’ll no doubt hit the wall again when you run this code on the user’s machine, you can’t copy DLLs into c:\program files without UAC elevation. This is really an installer task, it shouldn’t be in your code.