VS 2017 Debugger from c# Solution "The X# runtime is NOT loaded"

[m.evans]

Hello i.m trying to debug a X# dll through a mixed VB.net and c# solution under VS 2017 latest version , but its not possible to quickwatch a variable. I'm getting The X# runtime is NOT loaded. and in the watch window "Internal error in the X# compiler"
X# 2.18.0.4
Any hint about it?
Thank in advance

[robert]

Mike,
We recommend that you use VS2022 for this scenario.
We made some significant improvements to the X# debugger that only work with VS 2022 and not in VS 2017.

Robert

[m.evans]

Thanks Robert,
It's not possible to use VS 2022 because its a winforms app incompatible with VS 2022

[robert]

Mike,

Some winforms apps cannot be designed with VS2022, but there should not be a problem running the app in the debugger.

Robert

[VR]

You could try to migrate from VS 2017 to VS 2019.

[ic2]

Robert,

Some winforms apps cannot be designed with VS2022, but there should not be a problem running the app in the debugger.

In https://www.xsharp.eu/forum/topic?p=278 ... 022#p27894 you wrote:

if you develop for .Net Framework in VS2022 and use the internal windows forms editor, then there is also no problem.

This thread from Microsoft about this issue seems to suggest the opposite:

https://developercommunity.visualstudio ... -d/1601210

So, for .NET 6, .NET 5, and .NET Core applications you have full designer support . But if you have a .NET Framework application that is referencing a 32-bit component, this component cannot be loaded in Visual Studio 2022 Windows Forms designer, and you will see a white error screen instead. This will not affect your end users,


So where is the issue now: .Net 5/6/ etc, VS2022 and the Winforms Designer or .Net Framework, VS2022 and the Winforms Designer?

PS: Microsoft seems to have created a half solved solution and closed the ticket 2 months ago, as you can see in the thread.

Dick

[robert]

Dick,

There are various possible scenarios which, need different solutions:

.Net Framework:
- AnyCPU and X#: VS2017, VS2019, VS2022 (internal form editor)
- 32 bits and x#: VS2017 and VS2019
- 64 bits and X#: VS2022 (internal form editor)

- AnyCPU and C#: VS2017, VS2019, VS2022 (internal form editor)
- 32 bits and C#: VS2017 and VS2019 or VS2022 (external form editor)
- 64 bits and C#: VS2022 (internal form editor and external form editor)


Other .Net versions all require the external form editor for VS2022 and do not support X# yet.

Robert

[ic2]

Thanks Robert for the clarification.

One more question. You wrote:

- AnyCPU and X#: VS2017, VS2019, VS2022 (internal form editor)
- 32 bits and x#: VS2017 and VS2019

Our typical program says "Any CPU" in the the top toolbar and Platform Target: x86 in the Properties/Build section.

Does this mean we can use the (internal) Winforms editor (because of any CPU) in VS 2022? Or not because of "x86", instead of x64?

Dick

[robert]

Dick,

Platform Target is the determining factor.

Robert

[ic2]

Platform Target is the determining factor.

Hmm, this is more complicated than I thought. I have just read multiple articles and this is what I found - if anyone has comments or additional info, please post:

1 I routinely select "Any CPU" in the the top toolbar and x86 in the Properties/Build section as Platform Target which, I thought, would make my program run on the widest variety of Windows Pc and server versions
2 All Windows installations (except W11 and I assume newer Server versions) may have been installed 32 bits
3 x86 will run on 32 and 64 bit computers. However I found 1 article mentioning possible unexpected behavior on x86, in a SharePoint solution https://learn.microsoft.com/en-us/previ ... office.14) . And also that on some older Server versions, a program may not run https://www.solvps.com/blog/?p=1133. Finally: I can not use VS 2022 if I need to edit Winforms
4 Selecting AnyCPU makes the JIT emit 32bit code on 32bit systems and 64bit code on 64bit systems. But you need drivers for both, otherwise your program may not work
5 Selecting X64 makes VS2022 usable, could run your program a bit faster (except on minimal memory systems) but your program won't run on the occasional Pc's using a 32 bits Windows (installation). Does this mean that you have to investigate all used libraries - if any is 32 bits the whole program would fail?

For anyone reading this: what choice would you recommend ?

Dick