Known Issues
Last updated
Was this helpful?
Last updated
Was this helpful?
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
TreeControl nodes editor
Menu items editor
Data binding and the associated editors function as expected. However, it's worth noting that Microsoft has not yet provided an implementation for the typed DataSet editor. Currently, Microsoft suggests using the new Object Data Source Binding as an alternative to accommodate this gap.
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, as part of their ongoing initiative to improve developer security by protecting them from themselves.
Interestingly, they have reintroduced the same "unsafe" classes by offering them as a NuGet package.
This change affects all designer .resx files that contain values serialized with the BinaryFormatter. While these files are safe as internal .resx files — something even Microsoft acknowledges — they will not load properly in .NET 9 and above unless you include the following NuGet package reference in your project:
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.
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.
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.5.5, which consequently depends on System.Runtime.CompilerServices.Unsafe version 4.5.3. 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.
This versioning issue primarily occurs with the .NET Framework. Unlike .NET Core which 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:
Ensure you use the correct publicKeyToken with the actual public key token of the assembly. This configuration will redirect calls to different versions of System.Runtime.CompilerServices.Unsafe to the specific version (4.5.3 in this example) that is compatible with System.Drawing.Managed.
