Define a PowerShell BinaryFormatter Obsoletion Strategy #14054
Comments
|
BinaryFormatter is really only used by remoting for TimeZone. The only other case is the communication between |
|
cc @PaulHigin |
|
This seems to also hit remoting from .NET interactive, for which there doesn't appear to be a work around currently. |
|
@SteveL-MSFT @fMichaleczek we've recently managed to get our first .NET 6 builds of Devolutions Server, and we've encountered this issue which is fixed for now using EnableUnsafeBinaryFormatterSerialization. Can you confirm that whatever happens with the binary formatter deprecation, future versions of the PowerShell SDK will still be able to connect to older versions of PowerShell, especially for Windows PowerShell 5.1 over a WinRM transport? |
As said in the BinaryFormatter Obsoletion Strategy, the code will be removed in .Net 8. Until that you can use the code with EnableUnsafeBinaryFormatterSerialization. |
Yes, but that doesn't answer the question of backward compatibility with Windows PowerShell 5.1 servers when using a future .NET 8 PowerShell SDK client. I don't know how much it relies on BinaryFormatter, but is it possible to replace just the required bits in the PowerShell SDK such that it keeps working? BinaryFormatter may be deprecated, but Windows PowerShell 5.1 will still be officially supported for years to come as it ships built-in with Windows Server |
Obviously, the distance between .Net and the .Net Framework increases with each new version and the ecosystem is obviously splitting into two parts. As for PowerShell, this split has already happened and is doubly amplified by the split in .Net, so in my opinion it is not serious to talk about forward or backward compatibility. |
|
Correct me if I'm wrong, but from your answer it really looks like we're crossing fingers that by the time PowerShell uses .NET 8, Windows PowerShell 5.1 won't really be a thing anymore. I agree with deprecating BinaryFormatter, and it makes sense to drop support for it from the .NET runtime, but we need a plan to have a working PowerShell SDK that can still connect to the still-supported Windows PowerShell 5.1 when this happens. It is going to be there for a LONG time, it's built-in to Windows Server, and Windows Server has a long lifetime before reaching its EOL. I really don't know much about BinaryFormatter, and from Steve's previous answer, it looks like we're using it only in two places (time zones and Out-GridView). If someone could point to the source files affected maybe we could better assess ways to retain compatibility? Another possibility would be to move the required classes in a nuget package separate from the .NET runtime that could be used in PowerShell, like Microsoft.Windows.Compatibility: https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack
|
Current MSFT PowerShell team policy is to release next pwsh in the day next .Net version is released. |
IHMO, integrate System.Text.Json and JsonSerializer, is the first thing to do. Because it's the future and maybe the solution (clijson ?). |
|
I made a twitter thread about this yesterday, and @jborean93 came up with the simplest possible solution for the BinaryFormatter API obsoletion: https://twitter.com/BoreanJordan/status/1512978332887175170?t=VwkOfkZ-zt69Vj8J0TEJzA&s=19 All we really need is custom code to handle the time zone stuff during the connection sequence. It is benign in nature, and we could make a fix already such that connections work with .NET 6 without re-enabling BinaryFormatter. The real BinaryFormatter APIs are not required, Jordan was able to write custom code for the time zone stuff in his own Python implementation, there aren't that many possible combinations to handle. As for Out-GridView, it is only really used interactively, so I suggest we should update the PowerShell server not to use it unless it is already the case, and not bother about backward compatibility since interactive PowerShell clients can reasonably switch to PowerShell 7. non-interactive use through the PowerShell SDK is what truly matters. Should we create a separate issue to add a proper fallback for the time zone stuff in the current code base, link it to this issue? It would fix at least the current problem. As for other planned deprecated APIs, are there issues opened for all of them, and can someone link them here so we have a good idea of other issues coming up that would break backward compatibility with Windows PowerShell servers? |
|
A small point - I would not wish to see a "powershell server" edition as noted in the third para. |
|
Looking at the code a bit further, it seems like for the The other mentioned usage is with > "a" | Out-GridView
Out-GridView : Out-GridView does not work in a remote session.
At line:1 char:7
+ "a" | Out-GridView
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Power...GridViewCommand:OutGridViewCommand) [Out-GridView],
NotSupportedException
+ FullyQualifiedErrorId : RemotingNotSupported,Microsoft.PowerShell.Commands.OutGridViewCommanI have no idea if there are any other usages of
|
Any idea why it may not work in Azure Functions even if EnableUnsafeBinaryFormatterSerialization is set? |
|
As far as I know, binary formatter is supposed to be removed in .NET 8. Is this still on the radar? |
The updated plan is for the entirety of the |
|
Isn't this still a problem because of: dotnet/runtime#98245 |
|
See also: |
|
Another blog post dropped: How is this project going to resolve this. Are users now expected to use an unsafe and unsupported library?
|
|
So .NET 9 just dropped and since there was no recent activity on this issue i wonder what is going to happen moving forward? |
|
There is one issue at least #20300 |
|
It seems https://github.com/PowerShell/PowerShell/releases/tag/v7.5.0 provides Support for .NET9. Was there anything done about this issue?
|
|
BinaryFormatter is still used in Out-GridView. #20300 |
|
@fMichaleczek Thanks for pointing current tracking issue #24749 I mean we still have BinaryFormatter in our code. Really we use BinaryFormatter only to create deep copy of RuleFilter objects. There are ~20 classes based on RuleFilter. So we can make deep copy adding specific virtual method. Update: perhaps we could create custom json serializer? |
|
@iSazonov I dont understand your point. BinaryFormatter is gone in net9.0. https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md#binaryformatter-infrastructure-removed-from-net-net-9
|
|
@fMichaleczek It is still in code .Net has the class as dummy - to support compiling. |
|
+1, adding comment to track issue |
|
The strategy was that there was no strategy, apparently. I don't know what happened with PowerShell's development in recent years, but it's concerning. |
|
📣 Hey @@fMichaleczek, how did we do? We would love to hear your feedback with the link below! 🗣️ 🔗 https://aka.ms/PSRepoFeedback |
dotnet team has published his BinaryFormatter Obsoletion Strategy (07/23/2020)
There is already an impact for PowerShell 7.1 as ASP.NET projects disable BinaryFormatter by default (but can enable)
See #14032
The next impacts will be :
The documentation about BinaryFormatter security guide is published.
The text was updated successfully, but these errors were encountered: