2

We're building a commercial (closed/proprietary) intranet application which makes used of hosted IronPython (2.7), targeting .NET 4.0.

What approach would you recommend for ensuring the DLR runtimes (Microsoft.Scripting.dll & Microsoft.Dynamic.dll - both included in the IronPython 2.7 binary distribution) are available at runtime?

They're both licensed under Apache license so including with our software wouldn't be a problem. Potentially an alternative would be ensuring they're available in the GAC.

It seems the intention of the DLR developers is that more and more of the DLR will eventually end up in the .NET framework/CLR (presumably under System.Core).

Any thoughts or considerations are appreciated.

eddiewould
  • 1,555
  • 16
  • 36

1 Answers1

2

The best thing to do is include the DLR DLLs in your application next to the IronPython DLLs. Putting them in the GAC will affect every other application on the system that uses the DLR, which is probably not what you want unless you have complete control of the systems involved.

What's in .NET 4 is probably the extent of the DLR that's going to go in; Microsoft is not involved in the development of the DLR anymore.

Jeff Hardy
  • 7,632
  • 24
  • 24
  • When you say putting them in the GAC will affect every other application - surely there won't be any negative consequences given assemblies in the GAC are "strongly named" i.e. they're loaded not just by name and version but also by hash/signature also. Are there any performance differences between loading from the GAC and loading from the application directory? – eddiewould Sep 01 '11 at 20:45
  • I don't believe there's a performance difference, but I'm not sure. Any difference would be very tiny and only occur when the assemblies were first loaded. – Jeff Hardy Sep 06 '11 at 06:52