3

this is actually a follow up to a question I asked yesterday about problems with using older DLLs in Visual C# 2010. I have added the configuration file and the DLL runs well. The issue I'm having is that I would like to avoid having my entire project run in legacy mode.

I have gone around this by creating a new console project with command line access to all the functions I need from the DLL and read the output in my main project. This way it acts as a separate component, and I don't have to worry about legacy mode affecting anything in my main project.

The problem is that I feel as though this will really slow down my application in the long run, and since what I am developing needs to be fast, I was wondering if there is another approach to doing this. As I mentioned in the previous question, I cannot rebuild the DLL in 4.0.

Thanks,

PM

Community
  • 1
  • 1
user472875
  • 3,115
  • 4
  • 37
  • 68

2 Answers2

3

Sounds like you really misunderstand what that setting means. It most certainly doesn't mean that your project "runs in legacy mode", it is the exact opposite. The .NET 4.0 CLR version will be used by your old DLL with that setting. Instead of the new policy available in 4.0 that allows it to run with an old version of the CLR. Also known as in-process side-by-side feature. The new policy however doesn't support mixed-mode assemblies, that's why it complained.

You really don't want run it in a separate .exe with command line redirection, that's horrible. It is not only slow, it will make your app unreliable when the 'host' process dies on an unhandled exception but your main app doesn't notice. Very hard to diagnose.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • I agree with redirection being horrible, that's why I came here looking for help. I am still a bit unsure about what this setting actually does, but what kind of problems can I run into later on in development? (I've had this kind of issue before, and it's a nightmare to replace everything, when it turns out this setting causes a problem, and you're already half way through the project) – user472875 Dec 01 '10 at 06:50
  • I tried to explain it in my answer, maybe google can be more helpful. Long term, you should certainly worry about having chunks of code in your project that you cannot recompile or upgrade. Can't help you with that. – Hans Passant Dec 01 '10 at 06:55
1

It depends how frequently you call into it. If rarely, a process should be fine. If you call it a lot, then a lot of time is going to be spent on process-creation, reloading the dlls etc. You might improve this a bit by running NGEN on the console app, but I suspect a better option might be some basic IPC comms to a long-running exe or service. But keep the comms lightweight.

Another question is: have you profiled the process-based approach to see if this is actually an issue?

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • I guess I can modify the console project and keep it permanently running in a background process to access it, so I don't have to worry about loading it every time. (I need it almost constantly). What I was really wondering about is if there was any way to altogether avoid having to create a separate project and executable for this. – user472875 Dec 01 '10 at 06:29