Powershell: Coercion with System.Drawing not working in PS7

[jvierrajrv]

PowerShell 5.1 and earlier

[system.drawing.Pont]'10,20'

PowerShell 7 - fails to perform the coercion and all point assignments in WinForms controls (location,size, etc) fail to coerce the assignment.

[vexx32]

I'd say this is a likely to be an issue originating from the .NET Core side of things, given PowerShell was never really designed as a GUI tool first; it mostly likely only borrowed the existing defined casting operations provided in the .NET Framework which may be missing in Core.

[jvierrajrv]

I'd say this is a likely to be an issue originating from the .NET Core side of things, given PowerShell was never really designed as a GUI tool first; it mostly likely only borrowed the existing defined casting operations provided in the .NET Framework which may be missing in Core.

No. PS has always used "coercion". It is not a cast. This is not something that happens in the Net assemblies. How PS decides that the string is "coercible" is not documented but it has always worked even beyond WinForms. System,Drawing is not really part of WinForms but is fundamental to using WinForms. System.Drawing is the graphical class assembly used to manipulate images as well as other drawing primitives.

PowerShell has always been able to use WinForms assemblies. The assemblies are also available in PS 7.

System.Windows.Forms.dll and System.Drawing.DLL are delivered with PowerShell 7 and are in the preview folder. WinForms and the WinForms designer are part of PowerShell 7.

[vexx32]

Yes, PS has its own conversion logic. But it has never had specialized logic for System.Drawing assemblies as far as I've ever seen. Could be wrong, but we'd have to wait for the PS team folks to confirm that one. Might be a few days, they're mostly at PSConfEU at the moment. 🙂

It has a generic conversion routine when others fail, which can include (from memory) checking for Parse() methods that take the right argument type(s), looking for explicit or implicit operators, etc., etc.

Winforms isn't part of PowerShell's codebase. It's part of .NET Core 3, which is a dependency of PowerShell. PowerShell _might_ be able to manually fix this, but it would likely be better able to be fixed by the folks who actually maintain the WinForms code, is all. 🙂

[jvierrajrv]

You miss the point. WinForms is part of PowerShell 7.

The coercion has always been done in PowerShell. There has never been a constructor for System.Drawing.Point that takes a string.

[SeeminglyScience]

That conversion path utilizes the System.ComponentModel.TypeConverterAttribute that System.Drawing.Point declares in full framework. That attribute isn't declared on the version included with the Core assembly System.Drawing.Primitives.

[jvierrajrv]

Yes. This needs to be addressed to maintain compatibility with Windows PowerShell. That is the purpose of this post. PS 7 is set to replace WMF 5.1 on Windows and backwards compatibility is required.

[vexx32]

The place to address it, based on @SeeminglyScience's information, is in .NET Core where the type and its attributes are declared, then. 🙂

Please file the issue in the .NET Core repo so they can address the regression.

[msftbot[bot]]

This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.

[jvierrajrv]

Issue posted to Net Core.

I thank everyone for the guidance.

[karelz]

@vexx32 just FYI: dotnet/core repo is general incoming repo for random issues (no code). The code itself lives in CoreFx repo.

[vexx32]

Thanks, @karelz! So users wanting to file issues should primarily file against dotnet/core repo?

[karelz]

@vexx32 no, sorry for not being clear. dotnet/core is option for people who have no idea where to file an issue.
For close partner technologies like PowerShell that build closely on top of CoreFx, I would hope the community and maintainers know where their underlying APIs live - in dotnet/CoreFx repo. And that they should encourage repro steps without PowerShell when filing there.

The key reasons are:

1. It eliminates the chance it is something specific to PowerShell. (Avoids specialties like custom binding, Framework targeting, etc.)
2. It is more actionable as few (if any) devs in CoreFx know what PowerShell does under the hood and we have 0 knowledge about anything more complex/tricky/specific.

Note: Same approach is used for other higher-level technologies and frameworks like ASP.NET, WPF, WinForms, WCF, 3rd party libraries, etc. If we get repro steps from those, we first ask higher-level frameworks to be eliminated. Only in worst hard-to-repro-and-track-down issues we jump into investigations that involve the higher-level frameworks (and only if those are impacting multiple customers).

Does it make sense?
Is there any way we can help to spread the word about this in PowerShell repo community?
Thanks!

[vexx32]

That makes sense, thanks!

Some of that maybe should be mentioned in the contributing docs / issue templates or something here, I'm not sure myself. @SteveL-MSFT might have more concrete ideas there.

I think we may potentially run into a decent number of cases where folks aren't really familiar with how to tests things that they're seeing without PowerShell, so it might be on the rest of us in the repo here to put together simplified repro steps for testing and submission to dotnet/corefx as issues.

[jvierrajrv]

The PS guys claim it is a missing Interop in Core/FX. I kind of doubt that but they should know. thte above reference to the missing type sounds like a good start so someone should knock on Core/Fx to address this deficiency.

[vexx32]

@SeeminglyScience since you seem to know where the regression happened, could you open the appropriate issue in dotnet/CoreFX to get this resolved? 💖

[SeeminglyScience]

Thanks @vexx32, I've opened issue dotnet/corefx#38374

Also @jvierrajrv in the mean time you can use this as a workaround:

Update-TypeData -TypeConverter System.Drawing.PointConverter -TypeName System.Drawing.Point -Force

That will manually register the type converter for the session.

[karelz]

Thanks @SeeminglyScience for your help! Your CoreFX bug report is pretty clear and should hopefully make it into .NET Core 3.0 (fingers crossed). Thanks!

[jvierrajrv]

This is not in 3.0 - any chance it is in 3.1? PS 7 Preview 4 die snot have it, Some 3.1 seems to be in PS7 but this issue isn't.