I tried creating a new Oxygene WinForms application (using VS 2022 Enterprise). Using the .NET Core template, the designer doesn’t show up (trying to right-click / View Designer still shows the source code of the main form) and when I’m trying to run the application I get this error:
Error debugging project: exception: The remote server returned an error: (401) Unauthorized.
Even worse, trying to run without debugging (Ctrl-F5) generates the same error dialog.
I am afraid this part, at least, is “as designed” by Microsoft, who unfortunately explicitly disable use of the form designers by third-party languages, for .NET Core (classic .NETwill work).
This one is odd, as debugging a local app should not involve any HTTP requests to a remote server. Does this show as a popup dialog, or in the log? Can I see a screenshot of the complete error log? Does the same error happen for, say, a Console application or a non-.NET Core app?
I’ll loop in my colleague from the VS team who might have more ideas what could be going on here.
Ouch. Does that mean I must use Water for designing the UI? Or create all UI as C# WinForms? I guess that’s doable…
Here is a print screen of the error message. I don’t know how to identify the log.
The designer does indeed show up on a non-core app, but I still get the same error trying to run the application:
… and with a Core Console app:
and finally, with a classic console app:
Sorry, I didn’t expect the second monitor to be captured 
Hello Marcel.
Do I understand correctly that you cannot even run a simple console app (net framework) with the same error? I wonder what happens if you try to run Microsoft C# console app? Does it run properly?
For now, you’d have to use .NET 4.x to create GUI (the same code could the compile to .NET Core, fine.
okay, that is very strange; we cannot reproduce this here, and cannot think of what would cause a network request for debugging.
To rule out one more thing: if you create a non-.NET project (says Island/Windows native console app — do you get the same error? Using an Island project eliminates using the debugger provided by Visual Studio and uses our own, so that would help us rule out this coming from Microsoft’s .NET debugger…
Uff.
Pardon the language, that was a brainfart.
Only the Core apps show that error; the non-core (both Console and WinForms) work correctly, I just assumed they would automatically be set as the startup project when I created (instead, I was still trying to run the original one - the Core WinForms app). Strangely enough, the Core Console app DOES show that error.
So, this seems to be a Core-related issue. In case it matters, I recently (couple of days ago?) installed the .NET 7 RC1 from Microsoft.
I don’t have an “Island” option in the templates:
but a C# console app (.NET 6) runs fine:
Ok. this probably is an issue on Microsoft’s side then :(, but we’ll continue to investigate.
That’s Visual C# .NET 6, but the Elements project used .NET 7 RC? What happens if you make the VC# project sue NET 7, or the Oxygene one use .NET 6?
Island won’t show as language, but if you filter for Oxygene and Windows, Island/native projects should be in the list (the New Project dialog in VS is a bit messy, IMHO). But never mind that for now, as it seems we have narrowed this error down to being .NET Core specific at least (if Classic works, I expect Island will work too, so nothing gained by testing that).
Hmm… you are correct, the Oxygene projects use .NET 7. I didn’t see a way to select that when creating them, and changing them is difficult - I was able to change the runtime version but not the SDK version or the default value for the runtime:
Changing the runtime version to 6 did not help, I still get the same error. Changing it to .NET 7 for the C# console project still allows me to run it.
Check for the “Target Framework” project setting; it should read “.NET Core” (meaning latest) or e.g. “.NET Core 7.0”. Set it to “.NET Core 6.0” explicitly. I don’t expect - from the other infos — that it makes a difference, but that’s the way to set the version.
“SDK”/“SDK Version” and “Runtime”/“Runtime Versin” are derived from that, and should really only be changed in advanced scenarios (to pick a specific sub-version). I suggest you clear these settings to the (gray) default, again. to avoid that complicating things.
Changing the runtime version to 6 did not help, I still get the same error. Changing it to .NET 7 for the C# console project still allows me to run it.
Ok, it looks like we definitely need to debug this more. is there a chance my colleague could TeamView onto your machine and have a poke around (under your supervision of course)?
Sure, that would be highly appreciated! Is there a secure way for me to send you the connection details?
TeamViewer ID: 1 136 635 990
Password: n97jxxxr
Apologies for the delay.
Thank you for TV. I copied some callstacks and exceptions that we got but I can’t say now what exactly causes it. Need some time to investigate it.
That’s fine, thank you very much for doing that! I forgot that you can debug VS with VS
I think the problem is related to this, but changing it didn’t seem to improve things:
I know what fails, just not why.
.NET Core debugging requires a NuGet package that contains dbgshm.dll that is specific to the current platform and architecture of the debugged app. Because of that, we obtain this package dynamically when running, from NuGet — and that is what fails.
Two issues here.
1). Clearly this should fail with a better error; i’m not sure why it does not, and we’ll investigate .
2). more relevant the question is WHY this fails for you. Do yu have any network traffic blocked, are you behind any firewalls or the like?
Can you try something for me, please.
Does it build?
If so, does debugging in VS work, afterwards?
It fails to build:
“C:\Program Files (x86)\RemObjects Software\Elements\Bin\EBuild.exe” --logger:fire S:\temp\WaterCoreConsole1\WaterCoreConsole1.sln --configuration:Debug --build --setting:TreatFixableErrorsAsWarnings=True --xml:S:\temp\WaterCoreConsole1\obj\WaterCoreConsole1.water.xml --no-goal --verbosity:normal
RemObjects EBuild. An open source build engine for Elements and beyond.
Copyright RemObjects Software 2016-2022. All Rights Reserved. Created by marc hoffman.
Version 11.0.0.2785 (develop) built on bajor, 20221028-115800. Commit a23b1b2.
Reference ‘Echoes’ was resolved to ‘C:\Program Files (x86)\RemObjects Software\Elements\References\Echoes\NETCore5.0\Echoes.dll’ via XML for target ‘Echoes’.
E: Exception processing package reference Microsoft.Diagnostics.DbgShim:* : The remote server returned an error: (401) Unauthorized.
Project ‘WaterCoreConsole1’ failed to build.
Solution ‘WaterCoreConsole1’ failed to build project ‘WaterCoreConsole1’.
However, I don’t think I have any restrictions… I work with VS all day long, it’s what I do for a living and I don’t have any problems using NuGet.
That’s good at least, that’s the same error. This is very strange… but it definitely looks like a networking issue.
What happens if you add the same reference in VC#?
There is no problem adding the package to a regular C# project, building or running it.
I think there’s a confusion somewhere… I added that package to a regular C# project. I don’t know how to ask Elements to compile that one, I thought MSBuild takes care of it (and it does so successfully).
Weird thing though, I opened it in Water, right-clicked on that project and converted it to Elements, and now it compiles and runs successfully in Water:
In the references, I see that package showing up twice???
I’ll create another project and try again. I can’t send this message though… had to edit an older one.
I’ll continue to investigate this tomorrow
