Questions about choices: VS version, Dialect & .Net Framework version

[ic2]

1 After the replies on https://www.xsharp.eu/forum/topic/5548?p=33938#p33938 I started with updating Syncfusion (first time in nearly a year) and found that multiple common of their libraries required .Net 8 SDK. It took me a while to understand that this could only be selected from VS 2022 (or maybe a manual update from MS which was not fully clear). As I am reluctant updating any Microsoft product update I did not install VS 2022 so far but did now to enable Syncfusion to update.

My first impression, to my astonishment, is that it actually seems to work without new problems. But eventually, I opened one of my 4 WPF solutions which did not show the Design content apart from a windows bar where it does perfectly when the same solution is opened in VS 2019. Even worse: when I paste the xaml from one of the other 3 solution which does show correctly in VS2022 it doesn't anything show either.

Does anyone have an idea what could explain this?

And also I wonder: Are there any VS 2019 users who have not upgraded to 2022 (or kept VS 2019 besides 2022) for a reason, and if so, which? I did not see anything new or improved; what I read as improvements like being able to work in more memory does not apply to me.

2 During VS 2022 installation I noticed that older .Net Framework versions where checked as a default:

.Net Framework 4.7.2 targeting pack On removing it says it's needed by all kind of things like .Net desktop development
.Net Framework 4.8 targeting pack + SDK

But not 4.8.1 targeting pack + SDK

Why would VS components themselves rely on older .Net versions and what would be a reason not to use the latest .Net version except if you rely on an older referenced DLL based on that older version?

3 Which dialect. After installing VS 2022 and X# 2.23 some of my X# projects did not compile because I was supposed to include certain DLL's with the Vulcan dialect. I did not make any changes and I think haven't bothered about the used dialect for years but now I saw this message I was wondering which dialect I should use. Probably an old subject but I could not find earlier likely discussions because of the high number of search hits.

I know X# Core dialect is more compatible with C# but much VO like code won't work I understood so that won't be a good choice for my projects. What then is the recommended dialect? I would say VO as otherwise I need to keep using Vulcan DLLs?

Dick

[Chris]

Hi Dick,

X# does not yet support .Net > 4, so you need the 4-4.8 stuff for developing X# apps, old and new.

For VO-style development, your best option is to use the "VO" dialect, using normally the X# runtime. Just create a new project by selecting one of the VO dialect templates, and it will be already setup properly, with the correct X# runtime dlls. The vulcan dlls is a thing of the (very) past, when we had not completed the X# runtime yet, so developers needed to use their vulcan dlls instead (obviously they needed to have previously bought vulcan in order to own the dlls). Since many years now though this feature is obsolete and the vulcan runtime will not be supported anymore in the next X# release, so you simply need to use the X# runtime instead.

[wriedmann]

Hi Dick,
I cannot say anything about Visual Studio because I'm using it very rarely because I'm much more productive with XIDE, and also Andreas, my collegue, says the same thing ( he has done a lot of plugins for XIDE to support his own work).
Also I cannot say anything about framework versions as I'm still on 4.8 and will do the switch when X# and XIDE will support them.

What I can say about dialects: IMHO your choice is between VO and Core - I suppose you have no migrated Vulcan application that seems some compatibilities of this language.
Personally I'm using both: VO when working on legacy applications that were once in VO and migrated to X#, and needing the runtime.
The Core dialect is used when working on new applications, mostly WPF applications and some Windows services, where the development started from scratch and where I had no code from VO to use.
Using the VO dialect with the VO GUI classes and RDD classes is like using VO at steroids, with many possibilities to better structure your code, and use both VO and C# language constructs and libraries.

Wolfgang

[Fabrice]

Hi Guys,

Personnaly, I'm only using Visual Studio 2022. 2019 is still on the computer for some C++ "touchy" stuffs I'm using with students.
It runs fine and use all the power of my laptop (32GB) as it runs in 64bits mode.
Sometimes I add troubles with some XAML/WPF apps : This was due to DLL sideload, but I'm now only using NuGet packages to avoid these troubles : A Build will restore all the needed dependencies.

Dialect is a matter of :
Compatibilty - So use VO as you are used to it
Structuration - Core is my preferred choice for any new things.

You can already create and build Apps that are targetting .NET7/8/9, that's my case but not with "full" Visual Studio.
I have some tools, or RESTFull servers, running on .NET8 : I'm using VSCode for editing, and building ( the dotnet run command works like a charms), but these needs to be in Core Dialect.

[robert]

Dick
VS 2019 - 2022
VS 2019 is a 32 bits application. If you are using 32 bits 3rd party controls on forms, then you can only design these forms with VS2019. These forms will not open in VS2022. That is why some people keep using VS 2019 side by side with VS 2022. IIRC The IDE for VS 2019 needs .Net Framework 4.7.
The apps that you design can target any version of the .Net Framework. And your apps can also target x86 and x64 (or AnyCPU). The debugger in VS 2019 is also capable of debugging 32 bits and 64 bits apps.

VS 2022 is a 64 bits application. The IDE for VS2022 needs .Net Framework 4.8. Again: your apps can be any version of the .Net Framework.
Your apps can target both x86 and x64 (or AnyCPU). The debugger in VS 2022 is also capable of debugging 32 bits and 64 bits apps.

The other questions have been answered by other people.

If you do not need support for 32 bits components on forms, then I would recommend switching to VS 2022.

Robert

[ic2]

Thanks everybody for the extensive replies. The insight in the use of different .Net Framework versions from Robert was also very helpful.

To summarize:

1 We will change any X# solution which is (still) using Vulcan dialect to VO dialect. The first one I found did not even use any Vulcan DLL's. The compiler then gave 2 errors: I had to include XSharp.Core.DLL and XSharp.RT.DLL. I re-added the latest (4) X# assemblies, found that the solution still targeted .Net 4, changed that to 4.8 and it worked. I don't think we have any solution anymore actually using Vulcan DLL's, only maybe that the Dialect was Vulcan like this solution.

2 We will target .Net 4.8.1 as there is always a (small) chance that something is added or solved which is not present in earlier Framework versions. As we do not use the non framework .Net versions, it doesn't matter that X# does support these only from version 3. I don't think it's a problem for us when we remain on X# 2.23.

3 I understand Robert's advise to use VS 2022 and Fabrice's remark that a XAML/WPF issue could be dependency related which he solved with NuGet packages. As these have caused trouble almost every time I used them and the same solution works & shows the XAML Design window fine in VS2019, with the same dependencies, it doesn't make sense for me to use VS2022 as more issues are likely to emerge.

Currently solutions still open in VS2019 so I don't need to deinstall VS2022. This could also remove the .Net 8 SDK needed by Syncfusion while everything seems to work fine from VS 2019. Although I am still working in the C# WPF sample program (which targets .Net Framework 4.7) I want to continue in X# shortly.
Another reason to stay in VS2019 is that our Team Explorer server is from Bitbucket. To my surprise, they do not support VS2022 (which only requires an adapted plugin). Not sure what logic is behind this from their side. There will be a substantial number of users (eventually) working with VS2022 after all.

I assume that the Syncfusion installation requirement for the .Net 8 SDK has had no practical meaning given the target framework (and that I should be able to continue my Kanban project in X#).

Dick

[Kees Bouw]

Dick
VS 2019 - 2022
VS 2019 is a 32 bits application. If you are using 32 bits 3rd party controls on forms, then you can only design these forms with VS2019. These forms will not open in VS2022.
Robert

Hi Robert,

In the application I am working on we do have one Windows.Forms form with a 32-bit ActiveX control on it. A very important one that can't be missed. Is it that this form just can't be opened in VS2022, or does the control not even work? If the form only can't be opened that will not be a problem because I can't think of a reason why I would want to do that. But the control does need to work of course.

Kees.

[Chris]

Hi Kees,

It's only a problem with opening the form in the designer, at runtime it will work fine, provided of course that your app is a 32bit app.