See replies inline: On Thu, Jul 28, 2016 at 1:51 PM Mukul Sabharwal <mjsa...@gmail.com> wrote:
> Hello All, > > Sort of a lurking IronPython user, but I wanted to reach out to the > community on some work I've been wanting to do for a while now - > getting IronPython 2.7.X to run on .NET Core. > This is something we discussed in the Community Meeting today on Gitter. slozier is looking into this as well, so please coordinate so there is no duplicated effort. > > I've done preliminary analysis of IronPython and its dependencies > (excluding the AspNet and WPF stuff) and I believe getting 2.7.X to > run on .NET Core wouldn't be an astronomical amount of work. > > The major themes of the issues are: > > (1) Project Setup > (2) FEATURE_REMOTING > (3) FEATURE_WPF > (4) Debugging > > == Project Setup > > Today .NET Core supports a couple of different ways to setup projects, > the traditional csproj and an xproj setup. The tooling from Visual > Studio is integrated well for xproj, but the direction .NET Core is > moving in is to use csproj hence forth. So, in my mind using csproj > makes complete sense, and while the documentation is a bit sparse we > could setup csproj today to make .NET Core projects > We discussed this in the community meeting today and determined that we will look at the xproj/project.json for now and once csproj support is updated, we will using the conversion tool to convert to that. > == FEATURE_REMOTING > > This feature is not provided the cross-platform CoreCLR runtime, so > .NET Core support will invariably not be able to have this. > > That's fine, people won't want to use remoting if it doesn't exist on the platform anyway, so leaving this out is fine. > == FEATURE_WPF > > APIs around WPF are not available on .NET Core. I haven't dug deep as > to what IronPython.WPF really does but suffice to say it won't be part > of the .NET Core build either. > > Same goes for this, we don't ship stuff for .NET Core that isn't supported by .NET Core. > == Debugging > > This one maybe tricky to resolve just yet. The problem is that the > support for debugging runtime generated code is supplied by the CLR, > and is somewhat linked to the native debug format on Windows (PDB). > There maybe some challenges here around saving assemblies as well, but > it's possible to maneuver this space later on. > > I'm not familiar with IronPython 3's development status, hence I'm > leaving that out specifically from my work, but I suspect it would be > similar work to get it ready. > > And finally, if there are other interested members who are also > interested in helping out or doing more here please let me know. > > P.S. - I'm not very familiar with IronPython's rules of engagement, > i.e if mailing list is better or the GitHub pages, etc. So feel free > to point me in a certain direction. > > Mailing list is good. > Mukul > _______________________________________________ > Ironpython-users mailing list > Ironpython-users@python.org > https://mail.python.org/mailman/listinfo/ironpython-users >
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
