You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a legacy site and was going to upgrade IronPython to 3.4.1 (from 2.7), via nuget, and came cross build warnings in every project downstream from the one consuming ironpython - conflicts between WindowsBase 4.0 (IronPython dependency afaik) and WindowsBase 6.0 (dotnet system library)
Downgrading back to 2.7 sorts out the issue (and, in retrospect, it's probably what I want, considering language changes between python 2 and python 3), but it seems to be as if embedding IronPython in anything other than a windows GUI app isn't fully supported - I shouldn't need wpf dlls in my deployment, especially as it's being shipped off to a linux container.
Is this intentional? Is there a different package I should use?
Steps to Reproduce
create an asp.net website
create a class library project which depends on ironpython and make the asp.net website depend on that
build - this is when I see warnings
I've tried explicitly installing ironpython in the projects where the warning is emitted and that doesn't help. I'm reticent to apply assembly rebinds on a major version difference.
Expected behavior:
Should just build without requiring windows libraries
Actual behavior:
It seems like IronPython has a fairly hard dependency on WPF components (IronPython.Wpf.dll) which may make a lot of sense for GUI embedding, but makes little sense for, eg, a rules engine running in a service or website, and seems to tie the application to a win32 environment (but I'm not 100% sure - I backed out before attempting to break all the things 😅 )
problematic package: IronPython-3.4.1
.NET platform used: net8.0
Operating system used: windows (but the deployment target is linux)
The text was updated successfully, but these errors were encountered:
I tried to reproduce this with no luck. The only thing referencing WindowsBase is the IronPython.Wpf assembly which is entirely optional (there's nothing reference it). Note that the IronPython.Wpf assembly for .NET 6 (which would be picked up my .NET 8) should be referencing WindowsBase 6.0 so I'm not sure where the 4.0 version comes from. What's the target framework for you class library?
target framework is net8.0 - and the warnings were saying that the reason for WindowsBase issues was because of that assembly you mentioned (IronPython.Wpf.dll), so yes, I think we're in the same area; now to figure out how you don't get what I do... though, honestly, I'm likely to stay on 2.7 because we've phased out using python for config scripts in favor of JS (a little easier for the people who work on it in a web browser, not having to care about whitespace), but I didn't think that what I was experienced was intended, hence the report.
If I figure out more about this, I'll update here.
Description
I'm working on a legacy site and was going to upgrade IronPython to 3.4.1 (from 2.7), via nuget, and came cross build warnings in every project downstream from the one consuming ironpython - conflicts between WindowsBase 4.0 (IronPython dependency afaik) and WindowsBase 6.0 (dotnet system library)
Downgrading back to 2.7 sorts out the issue (and, in retrospect, it's probably what I want, considering language changes between python 2 and python 3), but it seems to be as if embedding IronPython in anything other than a windows GUI app isn't fully supported - I shouldn't need wpf dlls in my deployment, especially as it's being shipped off to a linux container.
Is this intentional? Is there a different package I should use?
Steps to Reproduce
I've tried explicitly installing ironpython in the projects where the warning is emitted and that doesn't help. I'm reticent to apply assembly rebinds on a major version difference.
Expected behavior:
Should just build without requiring windows libraries
Actual behavior:
It seems like IronPython has a fairly hard dependency on WPF components (IronPython.Wpf.dll) which may make a lot of sense for GUI embedding, but makes little sense for, eg, a rules engine running in a service or website, and seems to tie the application to a win32 environment (but I'm not 100% sure - I backed out before attempting to break all the things 😅 )
The text was updated successfully, but these errors were encountered: