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.
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…
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.
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:
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)?
.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.
Create a new .NET Core project in Water.
add a reference to “Microsoft.Diagnostics.DbgShim”
“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 126.96.36.19985 (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.
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.