Hi,
Is it ok to have inplicit references ? I thought it wasn’t. I created a .net core console app and changed the runtime and sdk version to 2.0 to see what it would do.
Is doesnt seem to be respecting my changes ? I closed and reopened the project just in case.
Also whats the general status of .net core ?
Thanks,
John
Sure it is. There are certain references that EBuild adds automatically to your project, when no matching reference is found. tis includes:
In the latter case, the version of the package will be set to the configured NETCoreRuntimeVersion. (Side note, looking at this now wonder whether this needs a [] around the version, to force the implicit reference to exactly match the runtime version…)
This only happens of you don’t have a matching explicit referent to the said dll or package. You can disable implicit package for .NET core. by setting DisableImplicitFrameworkReferences to true.
But: what specific problem are you seeing/trying to solve?
Plain .NET Core should be fully functional. ASP.NET Core is still a work in progress/not officially and fully supported.
I was trying to get a console app to talking to a sql server database using the SqlClient and dapper nugets.
I added Dapper and System.Data.SqlClient and I get these errors
E: Unknown namespace “System.Resources” in uses list [/Users/JohnMoshakis/Documents/develop/Echoes/Core/ConsoleApplication4/Properties/AssemblyInfo.pas (7)]
E: Unknown type “NeutralResourcesLanguage” [/Users/JohnMoshakis/Documents/develop/Echoes/Core/ConsoleApplication4/Properties/AssemblyInfo.pas (19)]
It also looked like debugging wasnt working and I was wondering if the dotnet application was fully integrated.
Cheers,
John
Could it be that .NET Core just doesn’t support the attributes used in the AssemblyInfo? Did you add any, or is this the unchanged file from template? Does it work if you just remove the namespace from using?
that said, my own test project has
namespace NetCoreApplication286;
interface
uses
System.Reflection,
System.Resources,
System.Runtime.InteropServices;
...
and it compiles fine, .NETCore2.1, Microsoft.NETCore.App runtime, version 2.1.2. What;'s your exact settings? Can I see a details re-build log?
There’s nots of variables here…
General debugging should be working, although I do have a few minor issues open that I need to look at. Can you elaborate on what “wasn’t working” entails, precisely? What fails, what’s the error?
thanx,
marc
ps: unrelated: I did make a couple fixes to package resolving today, one to make the implicit reference hardcoded to the appropriate version, and one to fix (affect non-fatal) “duplicate reference” warnings for .dlls being in both Micrsoft.NETStandard.Library and Microsoft.NETCore.App. I’ expect neither should affect your issue. I also fixed two (purely visual) issues foe the References tree in Fire not refreshing properly/immediately when changing NETCore version, or adding a new reference.
I didn’t change the template. I added this version of dapper
and that causes the build errors. That version only supports .net standard 1.3, I’ll try with later versions.
Creating a console app, build, setting a breakpoint on writeln and then running the debugger. Fire just sits there with
~> Process ConsoleApplication5 started
~> Trying to debug PID 52227
IN the console.
Is the Firehose still available ?
Cheers,
John
Curious. So it compiles w/o Dapper, but adding Dapper makes the namespace go away? That’s freaky. (and I also cannot reproduce this:
Final Output for 'NetCoreApplication286':
Dapper.dll (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Dapper.dll)
Dapper.xml (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Dapper.xml)
Echoes.dll (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Echoes.dll)
Echoes.dll.mdb (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Echoes.dll.mdb)
Echoes.pdb (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Echoes.pdb)
Elements.dll (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Elements.dll)
Elements.dll.mdb (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Elements.dll.mdb)
Elements.pdb (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/Elements.pdb)
NetCoreApplication286.deps.json (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/NetCoreApplication286.deps.json)
NetCoreApplication286.exe (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/NetCoreApplication286.exe)
NetCoreApplication286.exe.mdb (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/NetCoreApplication286.exe.mdb)
NetCoreApplication286.fx (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/NetCoreApplication286.fx)
NetCoreApplication286.runtimeconfig.json (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/NetCoreApplication286.runtimeconfig.json)
System.Data.SqlClient.dll (/Users/mh/Test Projects/NetCoreApplication286/bin/Debug/System.Data.SqlClient.dll)
I: FINALOUTPUT /Users/mh/Library/Application Support/RemObjects Software/EBuild/Obj/NetCoreApplication286-8E2E02A99D7E6E894B15682B5A31FDE8F55E3817/Debug/FinalOutput.xml
<- Task RemObjects.EBuild.Elements.ElementsCopyFinalOutput finished for NetCoreApplication286, took 0.0436s (4.5098s).
Can you give me a Diagnostic rebuild log log with (failed) and without (successful) the Dapper reference? Or can you send me the project?
Unrelated, let me upload my fixes from from earlier today as a new build, eta ~1h, just so you have that (although I also cant repro the issue with .2353, which is still what I have installed here…
Curious. Might be related to one of the issues I’m due to look at :(. Does the app run outside of the debugger?
Should be?
Up in Personal, also ofc in Firehose.
Thanks.
These are the logs with and without dapper. I tried 1.50.05 of dapper and it has the same problem.
Archive.zip (7.6 KB)
Whats the firehose url ? I’ve forgotten it 
The app runs fine outside the debugger.
One of em was not a rebuild. but oh well.
Couple tinges I. notice:
-> Target Echoes started.
D: Ignoring outdated cached data for ResolveReferences (11:09 PM ≥ 11:05 PM)
-> Task RemObjects.EBuild.Elements.ElementsProcessNuGetReferences started for ConsoleApplication5, Echoes.
D: Package Microsoft.NETCore.App found in local cache.
W: Package Microsoft.NETCore.App:2.1.0 has no deliverable for platform 'netcoreapp'.
I’ve improved the logging output here. This one will actually be diced by my new build; it happens because the implicit reference was not specific to a version, so it gets upgraded to the latest (2.2.0 here for me) which, indeed, does not have a deliverable for netcore2.1 (only 2.2).
The build I sent you last night already fixes this, as it pulls in [2.1.0] exactly, which works.
Right now, this issue is ignored (just a warning); and somehow the compiler pulls in the regular mscorlib.dll from Mono (that’s a compiler bug I need to log for Carlo for next week), which is why the build still succeeds.
I’ve now improved logging to show the actual version numbers:
D: Package Microsoft.NETCore.App:2.2.0 found in local cache.
E: Package <NameAndVersion = Microsoft.NETCore.App:2.2.0> has no deliverable for platform 'netcoreapp 2.1'.
and I’ve also made this a failing error instead of a warning, so the build will now fail if a (direct) package reference has. no deliverable. (indirect references without deliverable will remain non-fatal warnings only).
After fixing this, adding Dapper back to the project still/again compiles for me.
Can you retry with the new built from last night? in a short while, I’ll also send you a new build with the additional fixes I made, mainly for the better/more precise logging.
Uploaded the new build for you, develop-20181224-134504 - 0a500cb - 10.0.0.2354.
This is fixed. I needed to do a clean and then rebuild.
FWIW, Rebuild does a Clean as first step 
Fixed. One (known) debugger issue remains, when hitting breakpoints.
Can I get the latest from firehose ?
Whats the remaining issue ? I was trying to debug a mono console app and it didnt break on a breakpoint. In the end I had to kill Fire.
You’ll need a whole Fire build, which I need to do manually.
Thats that one, BPs would cause an internal NRE in the Core debug engine. Fixed that one just one.
I need to wait for a new compiler build (ca 50mins), then I can build a new Fire for you and upload it.
Up.
Thanks. Debugging in mono and core is working now.