Skip to main content

Known Issues

Collection Editors​

Editors, especially collection editors, present the most significant challenges when migrating to the out-of-process designer. As of now, we have integrated the following collection editors using the basic editor system that comes with the designer. However, we are planning to transition the more complex editors in an upcoming release.

  • DataGridView columns editor
  • TreeView nodes editor
  • Menu items editor

Data Binding​

Data binding and the associated editors function as expected. At the time of this release, Microsoft had not provided an implementation for the typed DataSet editor. Microsoft suggested using the new Object Data Source Binding as an alternative to accommodate this gap.

https://devblogs.microsoft.com/dotnet/databinding-with-the-oop-windows-forms-designer/

BinaryFormatter and .NET 9​

If you prefer to use .NET 9 or .NET 10 instead of .NET 8, you can do so with minimal issues. However, it's important to note that with .NET 9, Microsoft has completely removed the BinaryFormatter, because of security risks associated with binary deserialization.

The legacy implementation is available separately as a NuGet package.

This change affects designer .resx files containing values serialized with BinaryFormatter. To load those legacy resources in .NET 9 and later while migrating them to the newer format, the following package restores the legacy implementation. Use it only with trusted project resources; it retains the security risks of binary deserialization.

<PackageReference 
    Include="System.Runtime.Serialization.Formatters" 
    Version="9.0.0-*" />

In version 4.0.1 of Wisej.NET, we have completely eliminated the use of binary serialization. While you still require the System.Runtime.Serialization.Formatters package to open existing designer files that contain Responsive Profiles and Snap Lines, the binary serialization will not be used when saving these files.

tip

Once you have transitioned all existing binary resources to the new format, you can safely remove the System.Runtime.Serialization.Formatters package from your project dependencies.

System.Runtime.CompilerServices.Unsafe Hell​

The System.Runtime.CompilerServices.Unsafe assembly is known for potentially causing versioning conflicts when used in conjunction with the .NET Framework. In our latest System.Drawing.Managed library, designed for net48, we rely on System.Memory version 4.6.3 (AssemblyVersion 4.0.5.0), which consequently depends on System.Runtime.CompilerServices.Unsafe version 6.1.2 (AssemblyVersion 6.0.3.0).

However, issues arise when other third-party libraries reference differing versions of this assembly. This often leads to the familiar error message: "Could not load file or assembly or one of its dependencies. The located assembly's manifest definition does not match the assembly reference." Attempting to resolve one conflicting reference may inadvertently cause issues with another, resulting in a complex chain of version conflicts.

tip

This versioning issue primarily affects .NET Framework; .NET Core handles dependencies differently.

If you have the ability to modify the imported package, it is advisable to align its version with the one utilized in System.Drawing.Managed. However, if changing the package version is not an option, you can address the version conflict by using the web.config file to redirect the assembly version. Here is an example of how you can accomplish this:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-9.9.9.9" newVersion="4.0.5.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-9.9.9.9" newVersion="6.0.3.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Set publicKeyToken to the actual public key token of the assembly. This configuration will redirect the binding of System.Runtime.CompilerServices.Unsafe to the specific version 6.0.3.0, and System.Memory to 4.0.5.0.