Are there any plans to drop the .net 4.8 dependency? As far as I understood it is only required for the Designer.
The Microsoft Windows Forms designer is already dotnet 6 compatible. I guess it could be possible to migrate WiseJ’s designer. Are there any other blockers that require .net 4.8?
I’m asking because there are even some Microsoft libraries no longer supporting .net 4.8 ex. Microsoft.AspNetCore.Odata but we are trying to provide an OData interface beside die WiseJ UI. For now, we define conditional compilation with #if NET6_0_OR_GREATER to compile the assembly. We could also use conditional ItemGroups in the csproj but both ways are not very developer friendly.
Hi Bernhard,
The plan is to drop the designer dependency for .NET v4.8 and use the new .NET 6 designer.
We’re currently working on publishing a new roadmap with a timeline for this and other new features.
We’ll keep you posted as new developments are made!
Regards,
Levie
The designer available for .net 6.0? The sooner the better!
Please note, it’s honestly well-meant. I’m certain you already know. Seperate the editor and the output it stores from the actual code generator output. Use a code generator concept with an intermediate file like dotnet ... scaffold ... does for Entity Framework or ASP.net Razor frameworks.
The reason i’m referring to this is that the classic .net 4.8 designer using component model namespace enforces the use of a compiled binary where every detail is stored in the designer source code file itself. As a side note, this is the reason why the designer fails so many times when that file becomes modified, corrupt or unavailable eg. when cleaning the project … etc.
But the real obstructive reason is merging git branches containing *.Designer.cs files can become a tedious, unpleasant thing especially when multiple people work on a single WiseJ page/control/component up to a point where a merge gets impossible to do. We already had such unpleasant situations.
Whenever the designer opens up it’s screen dimensions vary depending on the developer’s desktop therefore the Location & Size properties of any control class on a page/component gets changed regularly. It’s even sufficient to open & close it without any change. Not only that this bloats the repository with unnecessary changes it makes merges nearly infeasible when two or more devs try to merge their changes. Have a look at the example image.
Hi Levie,
thanks for the feedback and looking forward for the new roadmap.
best regards
Bernhard
Please login first to submit.