[GH-ISSUE #102] Updgrade should use newly downloaded Configuration.exe

kerem commented

2026-02-26 10:35:41 +03:00

Owner

Originally created by @rbfajardo on GitHub (Oct 27, 2015).
Original GitHub issue: https://github.com/Pro/dkim-exchange/issues/102

I am getting an error when upgrading DKIM from 2.1.6 to 2.1.7.

Your Microsoft Exchange version isn't supported by the DKIM agent: 15.0.1130.7
I upgraded Exchange 2013 to CU10

Attached screenshot of error and version in hex

Originally created by @rbfajardo on GitHub (Oct 27, 2015). Original GitHub issue: https://github.com/Pro/dkim-exchange/issues/102 I am getting an error when upgrading DKIM from 2.1.6 to 2.1.7. Your Microsoft Exchange version isn't supported by the DKIM agent: 15.0.1130.7 I upgraded Exchange 2013 to CU10 Attached screenshot of error and version in hex ![version_not_supported](https://cloud.githubusercontent.com/assets/187106/10771198/86738ba4-7cbd-11e5-8db7-a2ee08b5e486.PNG) ![exchange_version_hex](https://cloud.githubusercontent.com/assets/187106/10771199/87ed0762-7cbd-11e5-9e20-555e85bcafea.PNG)

kerem

2026-02-26 10:35:41 +03:00

closed this issue
added the
bug

gui
labels

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@Pro commented on GitHub (Oct 27, 2015):

That's strange. It should be supported, at least the version is mentioned in the constants:
https://github.com/Pro/dkim-exchange/blob/master/Src/Configuration.DkimSigner/Constants.cs#L38

Are you sure that you upgraded to 2.1.7? Because the second screenshot mentiones 2.1.5. You can check the Properties Dialog of the .exe file (using Windows Explorer)

@Pro commented on GitHub (Oct 27, 2015): That's strange. It should be supported, at least the version is mentioned in the constants: https://github.com/Pro/dkim-exchange/blob/master/Src/Configuration.DkimSigner/Constants.cs#L38 Are you sure that you upgraded to 2.1.7? Because the second screenshot mentiones `2.1.5`. You can check the Properties Dialog of the .exe file (using Windows Explorer)

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@gogglespisano commented on GitHub (Oct 27, 2015):

I don't know if it's related, but when I do the update or reiinstall option, it updates all the files except Configuration.DkimSigner.exe which has an in use error, so the UI says 2.1.5 but almost all the files are actually 2.1.7.

@gogglespisano commented on GitHub (Oct 27, 2015): I don't know if it's related, but when I do the update or reiinstall option, it updates all the files except Configuration.DkimSigner.exe which has an in use error, so the UI says 2.1.5 but almost all the files are actually 2.1.7.

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@rbfajardo commented on GitHub (Oct 27, 2015):

My mistake, I did not launch the 2.1.7 "Configuration.DkimSigner" executable. I thought I could launch the existing one and do an online update. After launching the correct version of the executable, the installer updated the files.

@rbfajardo commented on GitHub (Oct 27, 2015): My mistake, I did not launch the 2.1.7 "Configuration.DkimSigner" executable. I thought I could launch the existing one and do an online update. After launching the correct version of the executable, the installer updated the files.

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@Pro commented on GitHub (Oct 27, 2015):

This may be the root cause for this problem... When the Update process is launched, the old dkim signer should close, but it seems that it is hanging somewhare and thus not closing which causes the copy operation to fail.

Maybe this bug was introduced in 2.1.5 where we updated the install process (https://github.com/Pro/dkim-exchange/releases/tag/v2.1.5).
The upgrading still needs some improvement (e.g. check if Configuration.DkimSigner is still running)

@rbfajardo Online Update should theoretically work, but due to the bug described, it still launches the old version.

@Pro commented on GitHub (Oct 27, 2015): This may be the root cause for this problem... When the Update process is launched, the old dkim signer should close, but it seems that it is hanging somewhare and thus not closing which causes the copy operation to fail. Maybe this bug was introduced in 2.1.5 where we updated the install process (https://github.com/Pro/dkim-exchange/releases/tag/v2.1.5). The upgrading still needs some improvement (e.g. check if Configuration.DkimSigner is still running) @rbfajardo Online Update should theoretically work, but due to the bug described, it still launches the old version.

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@AlexLaroche commented on GitHub (Oct 27, 2015):

The main problem is that we should load Constants.cs from a XML file that we can get versions of supported Exchange. During the upgrade process, we just have to load the new version of the xml file.

The problem is here in the code. (Install function in InstallWindow.cs)

foreach (KeyValuePair<string, string> entry in Constants.DKIM_SIGNER_VERSION_DIRECTORY)
{
     if (exchangeVersion.StartsWith(entry.Key))
     {
         agentExchangeVersionPath = entry.Value;
         break;
     }
}

@AlexLaroche commented on GitHub (Oct 27, 2015): The main problem is that we should load Constants.cs from a XML file that we can get versions of supported Exchange. During the upgrade process, we just have to load the new version of the xml file. The problem is here in the code. (Install function in InstallWindow.cs) ``` foreach (KeyValuePair<string, string> entry in Constants.DKIM_SIGNER_VERSION_DIRECTORY) { if (exchangeVersion.StartsWith(entry.Key)) { agentExchangeVersionPath = entry.Value; break; } } ```

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@Pro commented on GitHub (Oct 28, 2015):

The Constants.cs file is probably not the problem why the Configuration.exe doesn't close?
Creating an XML file just moves the constants into another place, so this wouldn't change much. It even makes the code more complex.

Maybe it's better to create an installer instead of the current approach? I.E. using Inno Setup.
Then the Configuration.exe downloads the installer and executes it. This will result in a more robust way for copying and installing the files. And it may be easier for users to install the signer.

@Pro commented on GitHub (Oct 28, 2015): The Constants.cs file is probably not the problem why the Configuration.exe doesn't close? Creating an XML file just moves the constants into another place, so this wouldn't change much. It even makes the code more complex. Maybe it's better to create an installer instead of the current approach? I.E. using Inno Setup. Then the Configuration.exe downloads the installer and executes it. This will result in a more robust way for copying and installing the files. And it may be easier for users to install the signer.

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@AlexLaroche commented on GitHub (Oct 28, 2015):

The Constants.cs is part of the executable. You can't close the file without reaload the executable.

The variable DKIM_SIGNER_VERSION_DIRECTORY should be in a XML file that we can load and unload having to restart the configuration application.

If you want to try to create a installer you cant try but your installer will have to be able to call external program to call powershell.

@AlexLaroche commented on GitHub (Oct 28, 2015): The Constants.cs is part of the executable. You can't close the file without reaload the executable. The variable DKIM_SIGNER_VERSION_DIRECTORY should be in a XML file that we can load and unload having to restart the configuration application. If you want to try to create a installer you cant try but your installer will have to be able to call external program to call powershell.

kerem commented

2026-02-26 10:35:42 +03:00

Author

Owner

@gogglespisano commented on GitHub (Oct 28, 2015):

Even if you put those values in an XML file, at some point you have to launch another process/installer AND close the current configuration executable or you wont be able to upgrade it during the install without an unnecessary reboot.

@gogglespisano commented on GitHub (Oct 28, 2015): Even if you put those values in an XML file, at some point you have to launch another process/installer AND close the current configuration executable or you wont be able to upgrade it during the install without an unnecessary reboot.

kerem commented

2026-02-26 10:35:43 +03:00

Author

Owner

@Pro commented on GitHub (Oct 28, 2015):

Yes, that's why I don't see any advantage using XML instead of Constants.cs

But Alex is also right, that an installer wouldn't be that simple since it needs to call some Powershell Snippets.

So as a conclusion:
We need to improve our install process and find out why the Configuration.exe isn't properly closed here: https://github.com/Pro/dkim-exchange/blob/master/Src/Configuration.DkimSigner/MainWindow.cs#L582
I think that one of the threads running in the background isn't stopped properly.

@Pro commented on GitHub (Oct 28, 2015): Yes, that's why I don't see any advantage using XML instead of Constants.cs But Alex is also right, that an installer wouldn't be that simple since it needs to call some Powershell Snippets. So as a conclusion: We need to improve our install process and find out why the Configuration.exe isn't properly closed here: https://github.com/Pro/dkim-exchange/blob/master/Src/Configuration.DkimSigner/MainWindow.cs#L582 I think that one of the threads running in the background isn't stopped properly.

kerem commented

2026-02-26 10:35:43 +03:00

Author

Owner

@AlexLaroche commented on GitHub (Oct 28, 2015):

Configuration.exe is properly closed. The problem isn't there.

The executable currently reload itself, not the new Configuration executable that will be downloaded later in the install process.

We can use Shadow Copy (http://blogs.msdn.com/b/junfeng/archive/2004/02/09/69919.aspx) feature to load the executable in memory and overwrite the existing executable be cause the file will not be lock (Shadow Copy).

After the new files is copied, we can load the new executable to complete the install process with a specific switch like "-install-continue".

@AlexLaroche commented on GitHub (Oct 28, 2015): Configuration.exe is properly closed. The problem isn't there. The executable currently reload itself, not the new Configuration executable that will be downloaded later in the install process. We can use Shadow Copy (http://blogs.msdn.com/b/junfeng/archive/2004/02/09/69919.aspx) feature to load the executable in memory and overwrite the existing executable be cause the file will not be lock (Shadow Copy). After the new files is copied, we can load the new executable to complete the install process with a specific switch like "-install-continue".

kerem commented

2026-02-26 10:35:43 +03:00

Author

Owner

@Pro commented on GitHub (Oct 28, 2015):

Ok, then we shouldn't wonder why updating fails!
My first version launched the newly downloaded .exe, which is the right way to do it. (See github.com/Pro/dkim-exchange@a2e69eaa15 (diff-80fbe89954)).
But it seems that this was changed during some refactoring, which is bad.
Using the just downloaded .exe allows us to fix bugs in the install process if the old exe fails and of course doesn't lock the currently installed files.

I will change this back as it was.

@Pro commented on GitHub (Oct 28, 2015): Ok, then we shouldn't wonder why updating fails! My first version launched the newly downloaded .exe, which is the right way to do it. (See https://github.com/Pro/dkim-exchange/commit/a2e69eaa15bd64a024fb60094f2a4a2086604500#diff-80fbe899548913d9af44190d7c253f97R756). But it seems that this was changed during some refactoring, which is bad. Using the just downloaded .exe allows us to fix bugs in the install process if the old exe fails and of course doesn't lock the currently installed files. I will change this back as it was.

kerem commented

2026-02-26 10:35:43 +03:00

Author

Owner

@AlexLaroche commented on GitHub (Oct 29, 2015):

Download the package "Configuration.DkimSigner.zip" from the lastest release, extract the content and execute the "Configuration.DkimSigner.exe" from MainWindow.cs.

You could take example on what have been done in InstallWindow.cs.

The problem could be solve without rollback all the code changes. If you rollback all the changes, you will reintroduce thread bugs that is bad too. A lot of work have been done to make them work without bugs.

@AlexLaroche commented on GitHub (Oct 29, 2015): Download the package "Configuration.DkimSigner.zip" from the lastest release, extract the content and execute the "Configuration.DkimSigner.exe" from MainWindow.cs. You could take example on what have been done in InstallWindow.cs. The problem could be solve without rollback all the code changes. If you rollback all the changes, you will reintroduce thread bugs that is bad too. A lot of work have been done to make them work without bugs.

kerem commented

2026-02-26 10:35:43 +03:00

Author

Owner

@Pro commented on GitHub (Oct 29, 2015):

Sorry, my comment wasn't really clear.
I did not mean to rollback the code but to change this behavior back to the old one using the current code

@Pro commented on GitHub (Oct 29, 2015): Sorry, my comment wasn't really clear. I did not mean to rollback the code but to change this behavior back to the old one using the current code

kerem commented

2026-02-26 10:35:43 +03:00

Author

Owner

@gogglespisano commented on GitHub (Oct 31, 2015):

I installed 2.1.8 and I was then able to reinstall without getting the file in use error.

@gogglespisano commented on GitHub (Oct 31, 2015): I installed 2.1.8 and I was then able to reinstall without getting the file in use error.

Rows
Columns

[GH-ISSUE #102] Updgrade should use newly downloaded Configuration.exe #79