0

I have (source code) a mixed-mode (.NET 2.0) DLL-assembly that is a TAPI telephony service provider. So it is loaded by the Windows Telephony Service (svchost). This works as expected in Windows XP, Vista and Windows 7 when .NET 2.0 or 3.5 is (pre)installed.

Now I am targeting Windows 8 with .NET 4 preinstalled. The problem I am faceing is that Windows will not load the DLL (and TSP) with that configuration. When I install .NET 3.5 everything works fine but I'd rather not like to force users to install .NET 3.5 in addition to .NET 4 already present.

I allready read What 'additional configuration' is necessary to reference a .NET 2.0 mixed mode assembly in a .NET 4.0 project? but this does not apply because I do not have an application and thus no app.config file.

According to http://reedcopsey.com/2011/09/15/setting-uselegacyv2runtimeactivationpolicy-at-runtime/ it seems to be an interesting approach to setup the useLegacyV2RuntimeActivationPolicy before loading the mixed-mode assembly. But I guess this will not work in my case because the assembly is loaded by the telefony service.

Or is this possible in the mixed-mode assembly itslef? The assembly is always invoked by unmanaged calls from the Windows service. Is it possible in such a call to set the policy in the unmanaged code part before creating the first gcroot or is this already too late? If it's possible, how would I obtain and call the required COM object to do so?

Community
  • 1
  • 1
Gandalf
  • 2,350
  • 20
  • 28
  • Is there any way to just make this a .NET 4 or 4.5 assembly? Trying to set the runtime policy at runtime is very problematic (it works, but it can fail if anything else has already run, etc). – Reed Copsey Jul 22 '13 at 16:52
  • You might also want to take a look at http://www.shujaat.net/2012/11/portable-retargetable-assemblies.html not sure it will help... but it's worth a look – Mgetz Jul 22 '13 at 16:54
  • @ReedCopsey I guess .NET 4 is the best choice to go then although this would make us force a lot of users (Windows XP) to update to .NET 4 or of course provide two different versions which is not a viable option because this would have severe impact on the whole packaging and deployment process. – Gandalf Jul 23 '13 at 12:36
  • @Gandalf Updating to 4.0 in your deployment is likely FAR simpler than trying to maintain this. 4.0 supports XP users (though they should be leaving XP soon anyways, given its near term EOF), and avoids this entire issue. – Reed Copsey Jul 23 '13 at 16:20
  • Actually we went the way of updating the assembly to .NET 4. And it worked out quite well with our customers :) – Gandalf Jan 13 '14 at 12:18

0 Answers0