2

This is a sister question along with my first question Allow C# application built with .NET 2.0 to run on .NET 4.0/4.5. I simplified my situation a little bit there for understanding. Actually our case is a little special.

Basically we wrote a C# DLL (Let's call E.dll) for our MSI installer. Since our MSI installer is using older version of windows installer, it could not use C# DLL directly and it could only work with C type DLL, so we use an open source library called DLLExporter to generate the C export function entry port. The E.dll is built with .NET 2.0 (VS2005).

As my first question is stated, we have trouble to run our installer on machine where only .NET 4.0 or above is installed. After some effort and help from this excellent forum as well, I think that I started to understand the issue, and here is the final application configuration file:

<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v2.0.50727"/>    
  <supportedRuntime version="v4.0"/>        
</startup>

Due those C export function entry point, the final C# dll is considered a mixed mode assembly, so I need the useLegacyV2RuntimeActivationPolicy as "true" on .NET 4.0.

However there is one issue, the configuration has to be on the exe, but not on the DLL. I confirmed this by using a test harness exe which dynamically loads the E.dll like our MSI. let's call test harness exe as T.exe. So by having E.dll.config as above content won't help. We need the T.exe.config file. However for our MSI installer, it is msiexe.exe which is located at C:\windows\system32 and we can not put a file called msiexe.exe.config into system32 (I just tested it and it doesn't work and I still need to figure out which exe I should have the app.config file). No matter which exe, it is a mess. I won't be able to solve this problem by building the DLL in .NET 4.0 (VS2010) since I would need the config file to set useLegacyV2RuntimeActivationPolicy to "true".

Any idea how I could have the app.config on the DLL instead of on exe?

Community
  • 1
  • 1
windfly2006
  • 1,703
  • 3
  • 25
  • 48

1 Answers1

1

My recommendation would be to use a trampoline .EXE to spawn the .NET DLL out-of-process.

The msiexec.exe.config didn't work because msiexec.exe has an embedded manifest.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • thanks very much. Could you give a little more details or send a link for why embedded manifest would prevent msiexec.exe.config file from working? If possible, could you give a little more details about implementing this trampoline .exe as well? Right now, we use a custom action which would save the .dll to disk and then load the library dynamically from disk. I could add more details around this by checking with our MSI developer if required. – windfly2006 Nov 20 '12 at 12:07
  • we are thinking the implementing the trampoline .exe in pure C++ and the dll won't need the C export function entry point as well. – windfly2006 Nov 20 '12 at 13:27
  • The loader looks for a manifest in the .exe file and if not found then it looks for .exe.config file. The trampoline exe can be implemented any way you want. The idea is to extract it and all its dependencies, then launch it as a custom action. – Joshua Nov 20 '12 at 16:12