I have 3 managed C++ DLLs compiled with VS 2003 against framework 1.1. One of them also has unmanaged code it in. The unmanaged code in the that DLL is called from an unmanaged Delphi application. (The DLL is loaded via a LoadLibrary call in the Delphi application.) The transition from unmanaged to managed is done via IJW. I make no calls to create/host my own application domain.
This has been working fine on all systems with just 1.1. It has also worked on MOST systems with framework 2.0 installed. It has failed on 2 out of 3 Windows 2000 systems and 1 out of 20 or 30 XP systems. Removing 2.0 from the 2000 systems allows the app to run. Reinstalling 2.0 breaks it again. The XP system is a different case. It had J# beta 2 on it and it appears that framework 2.0 is half installed and will not completely uninstall. Removing J#, installing framework 2.0 and removing framework 2.0 left the 2.0 configuration utility in the start menu.
I will freely admit that I don't understand how the managed environment is getting activated in my scenario and therefore I have no idea how (if it is even possible) to indicate that the resulting app domain should be a 1.1 domain etc. I simply followed the guidance that Microsoft gave me as to how to make this application work.
The problem that I need to understand and solve first is the problem with the 2000 systems. If we can solve the problem on the XP system also that is even better.
I have no error code or error message. All I have is a load failure from the Delphi application indicating that it could not load the first of my managed DLLs via the LoadLibrary. All DLLs are strongly named.
Thanks for you help and suggestions.
.Net Framework 2.0 prevents 1.1 DLL from loading
Kenny99
I'm not familiar with Delphi, but if the loading mechanism is COM Interop or similar you should be able to force it to use the 1.1 Framework by adding the following to your application configuration file (YourDelphiApp.exe.config in the same directory as YourDelphiApp.exe):
<
xml version="1.0" encoding="utf-8" ><configuration>
...
<startup>
<requiredRuntime version="v1.1.4322" safemode="true" /> </startup></
configuration>DaveJW
Roy, did this situation ever resolve
I am experiencing the very same problem with some v1.1 managed C++ dll's which interface with native code. I'd sure like to know what the hangup is. I have been speculating that while my 1.1 application is executed by the 1.1 framework, these managed C++ dll's may be getting loaded by the 2.0 framework, resulting in a load failure of some sort.
bamacoder
Thank for your response, but I am NOT using COM Interop. It is a simple LoadLibaryEx followed by several calls to GetProcAddress to determine the entrypoint addresses of the unmanaged entrypoints in the managed code DLL. The unmanaged code simply calls the managed entrypoints and all works.
I don't have a .config for the exe, I ASSUMED that it would not be looked at, because the initial load of the exe does not force the app domain to be created. (It is not created until the DLL makes its first unmanaged to managed call.)
I would be glad to listen if someone could tell me my assumption was incorrect. I see a foot note in the doc on requiredRuntime version that indicates it is ignored by the startup code in IE. While, my app does not start from IE, I would expect that it would be ignored in may case also. Anyone have an opinion on this based on expierence or knowledge of the code.
glenrm
> I don't have a .config for the exe, I ASSUMED that it would not be looked at
It's easy to test this assumption, why don't you just create a config file
> I would expect that it would be ignored in may case also.
You're right. Having looked at the .NET 2.0 docs I see that the requiredRuntime is for .NET 1.0 apps only. You should use the <supportedRuntime> element instead.
vlad icrm
I put the following .config file in the directory with the unmanaged .exe. IT WORKED. Surprised the heck out of me. I had assumed that the loader (at EXE load time) looked for and processed the .config file, but appearenty the .net framework initialization code does the work later.
In retrospect I guess it should not have been much of a surprise.
Of course the file is NAME.exe.config
< xml version="1.0" encoding="utf-8" >
<configuration>
<startup>
<supportedRuntime version="v1.1.4322"/>
</startup>
</configuration>