.NET 4 Windows service install upgrade error

1
votes

I have a .NET 3.5 Windows service which is installed using a VS2008 Setup & Deployment project. It has a custom install action. The installation of this service worked great until I recently upgraded to VS2010/.NET 4. Now, when I upgrade to the new version, I get the install error: "Error 1001...BadImageFormatException: Could not load file or assembly...This assembly is built by a runtime newer than the currently loaded runtime...". If I uninstall the previous version and then install the new version, everything works fine...no errors. The install is being performed on my development machine so the .NET 4 framework is already there.

I enabled Fusion logging and found an error file (see below). The service "ServerService.exe" is being loaded by the .NET 2.0 framework, but I am not sure why this is. Other files in the install are loaded by the 4.0 framework. Does anyone have any suggestions on how to fix this or how I can investigate this further?

The project targets the .NET 4.0 framework and my app.config contains the following lines:

  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>

Thanks,
Steve


Fusion Log:

Assembly Binder Log Entry  (3/11/2011 @ 2:44:03 PM)

The operation failed.
Bind result: hr = 0x8013101b. No description available.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  C:\Windows\syswow64\MsiExec.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = NT AUTHORITY\SYSTEM
LOG: Where-ref bind. Location = C:\Program Files (x86)\Server\ServerService.exe
LOG: Appbase = file:///C:/Windows/syswow64/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===<br>
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: No application configuration file found.
LOG: Using host configuration file: C:\Users\Steve\AppData\Local\Temp\CFG94A5.tmp
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Server/ServerService.exe.
LOG: Assembly download was successful. Attempting setup of file: C:\Program Files (x86)\Server\ServerService.exe
LOG: Entering run-from-source setup phase.
ERR: Error extracting manifest import from file (hr = 0x8013101b).
ERR: Failed to complete setup of assembly (hr = 0x8013101b). Probing terminated.**
2
.netwindowsserviceinstallation
Take a look at this question on SO: stackoverflow.com/questions/3953063/… – Ta01
The uninstall custom action is running the old application. That could be part of the problem. Also another thing to check is did the version number of the MSI change, and did the assembly versions change on the exe/dll files? (if they're the same versions, they may not be replaced and therefore the old files are still in place) – randbrown
Yes, I would tend to agree that it seems like the uninstall custom action is somehow the source of the problem. Unfortuately, I don't know how to go beyond the point where I am at to troubleshoot this further. The setup project's version property was incremented (along with the ProductCode property). – Steve
While watching the install's target folder, I see all of the files update to the new version and then I get the BadImageFormatException error. It's as if the uninstall custom action is occuring after the files have been copied but running under the .NET 2.0 framework (i.e. it is trying to load the new version of the service). – Steve
Did the assembly versions change? That might make a difference. And yes the order of the uninstall is not what you'd expect (in fact many people, myself included, have gone to great lengths to put it back to the old order by using post build actions with scripts to modify the MSI tables). – randbrown

2 Answers

0
votes

When I remove the custom actions from my application, the upgrade works just fine so I guess I've pinpointed the source of the problem.

0
votes

I have an unmanaged C++ EXE calling a .NET DLL through COM.

What needs to be mentioned here is that the <startup>... block, listed above, needs to be added to foo.exe.config, as well as app.config (where foo.exe is your executable). The config file needs to be present in the install directory.

I was getting the exact same error, because FUSLOGVW showed that Windows was loading .NET 2 framework although I was compiling against .NET 4. I had formatted my app.config but that wasn't enough.