Motivativation

Moving away from BinaryFormatter is a long running coordinated dotnet effort, all first party code should be migrated away during .NET 8 timeframe

Context

MSBuild is using BinaryFormatter in couple places as a fallback mechanism for de/serialization of more complex types (AppDomainSetup, Exceptions, ValueTypes etc.) as well as for de/serialization of custom, pluggable data (BuildEventArgs, Embedded resources)

Scope

NET 8 - need to remove or developer-condition MSBuild usages of BinaryFormatter

• GenerateResource Task (+ resgen) - Action plan needed - we can slowly deprecate this, but viable replacement needs to be thought through. Cost: Unknown, Breaking: Yes
  • [BinFmt] Identify usages of GenerateResource task #8827
• BinaryTranslator.TranslateDotNet
  • TranslateException Depart BinaryFormatter for Exceptions serialization #8786 Cost: M, Breaking: No
  • AppDomainSetup: [BinFmt] AppDomainSetup #8922 needed for OutOfProc (TaskHostConfiguration) and Separate AppDomain Tasks (NodeConfiguration)) - it seems all we need are actually 'ConfigurationBytes' (https://github.com/dotnet/msbuild/blob/main/src/Shared/TaskLoader.cs#L95-L99) - so hopefully limited cost, but needs investigation. Cost: S (TODO: detailed investigation to confirm), Breaking: No
  • ValueType and ValueTypeArray task parameter types [BinFmt] ValueType and ValueTypeArray #8923 (usage) - We should be able to de/serialize without BinaryFormatter (Blittable types just be grabing the bytes, nonblittable by marshaling) - this should be relatively easy and isolated. Cost: S, Breaking: No
  • BuildEventArgs
    • MSBuild first class citizen events - all serialized without BinaryFormatter (either via LogMessagePacketBase special handling, or via reflection discovered methods on types). No work here
    • Custom BuildEventArgs [BinFmt] Custom BuildEventArgs de/serialization #8823 - de/serialization approach from TranslateException should likely be way to go here. It's breaking though. Cost: M, Breaking: Yes
    • [BinFmt] Identify and notify internal partners relying on custom BuildEventArgs #8825 Internal partners relying on custom BuildEventArgs need to be discovered (code search within GH, AzDO accross all our build event types), notified and brought to discussion (code search). Cost: S-M
    • @Forgind already identified FxCop as relying on this. It's removed from VS, but will continue to ship as optional component via nuget (PoC: @mavasani(?) - so it might be FullFW only?)
    • [BinFmt] Facilitate proper documentation of Custom BuildEventArgs deprecation and replacement #9016
    • [BinFmt] Opt-in warn on Custom BuildEventArgs usage #9008
    • [BinFmt] Support extended messages in binary log and binary viewer #9091
    • [BinFmt] Add build-in 'ExtendedCriticalBuildMessageEventArgs' #9355
  • Tests [BinFmt] Rework/Remove unit tests using TranslateDotNet #8924
    • exceptions (just remove or move to TranslateException) Cost: XS, Breaking: No
    • ProfilerResult - most likely just remove, as this most likely uses only ITranslatable Cost: XS, Breaking: No
• [BinFmt] Investigate the need of removal from deprecated code #8822 currently 11 usages. Hopefuly this doesn't need to be touched, or at worst just conditioned, otherwise cost might be significant. Cost: Unknown, Breaking: Unknown
• Unit tests [BinFmt] Rework/Remove unit tests using BinaryFormatter #8925
  • Build.UnitTests - testing deserializing exceptions - should be moved to new eceptions de/serialization mechanism. Cost: S, Breaking: No
  • Framework.UnitTests - testing deserialization of EventArgs, AssemblyNameEx, CopyOnWriteDictionary - should be moved to new deserialization once implemented. Cost: S, Breaking: No
• StateFileBase and extensions
• GetSDKReferenceFiles task

post NET 8 #

• [BinFmt] Custom Build Event Args will lead to build warning/error by default #9300 - Cost: XS, Breaking: Yes
• Communicate the .NET Framework breaking change to internal partners. Facilitate documentation update for VS 17.? - Cost: S
• Remove serialization attributes, GetObjectData, (SerializationInfo, StreamingContext) constructors, etc. (to align with the plan - deprecation of types) Cost estimate: S-M