Internal error: RemObjects.Elements.Cirrus.CirrusException: Unknown identifier "System.Threading.Monitor"

JohnMoshakis · January 31, 2019, 5:49am

Hi,

Im getting an internal error while building a test app.

              Reference: /Library/Frameworks/Mono.framework/Versions/5.16.0/lib/mono/4.5/mscorlib.dll
              -> Phase Resolving Bodies started.

E: Internal error: RemObjects.Elements.Cirrus.CirrusException: Unknown identifier “System.Threading.Monitor”
at RemObjects.Elements.Cirrus.ProxyCache.GetType (System.String fullname) [0x0001c] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at (wrapper remoting-invoke-with-check) RemObjects.Elements.Cirrus.ProxyCache.GetType(string)
at RemObjects.Oxygene.Code.Compiler.Compiler.CreateGenericFutureHelper (RemObjects.Oxygene.Code.IParsedType pt, RemObjects.Elements.Cirrus.ProxyCache lCache, RemObjects.Elements.Cirrus.AspectProcessor pr, RemObjects.Oxygene.Code.Compiler.FutureInfo fi, RemObjects.Oxygene.Code.CodeFile aFile, System.Boolean aUsePFX) [0x00341] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.Compiler.Compiler.GenerateFutureHelperClassPFX (RemObjects.Oxygene.Code.Compiler.FutureInfo fi, RemObjects.Oxygene.Code.CodeFile aFile) [0x00027] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.Compiler.Compiler.GenerateFutureHelperClass (RemObjects.Oxygene.Code.Compiler.FutureInfo fi, RemObjects.Oxygene.Code.CodeFile aFile) [0x0001a] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.Compiler.Compiler.GetFutureInfo (RemObjects.Oxygene.Code.IPosition aErrorPos, RemObjects.Oxygene.Code.CodeFile aFile) [0x008f4] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.CombinedParsedType.CheckMethod (RemObjects.Oxygene.Code.IMutableMethodImplementation element) [0x0072c] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.CombinedParsedType.AddMethod (RemObjects.Oxygene.Code.MethodDefinition aMD, RemObjects.Oxygene.Code.Compiler.ScopeInfo& lScope, RemObjects.Oxygene.Code.LoadMembersFlags& aFlags) [0x003a3] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.CombinedParsedType.LoadMembers () [0x0062f] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.CombinedParsedType.GetMembers () [0x00009] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.Compiler.Compiler.ResolveType (RemObjects.Oxygene.Code.Compiler.ScopeInfo lScope, RemObjects.Oxygene.Code.IParsedType aType) [0x0059b] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.Compiler.Compiler+<>c__DisplayClass49.b__4 (RemObjects.Oxygene.Code.IParsedType aType) [0x00000] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.Compiler.Compiler.ForAllInternalTypes (System.Action`1[T] aAt) [0x0007b] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
at RemObjects.Oxygene.Code.Compiler.Compiler.ResolveMembers () [0x001de] in <94fbf2c79e274fa7bdaa1a985e28012c>:0
E: Could not find a “Main” method in this project
<- Phase Resolving Bodies finished, took 1.4267s.
-> Phase Checking Members started.
<- Phase Checking Members finished, took 0.0825s.
-> Phase Generating Helper Types started.
<- Phase Generating Helper Types failed.
<- Target Echoes failed compiling.

Cheers,
John

RemObjectsSoftware · January 31, 2019, 7:09am

Thanks, logged as bugs://81859

ck · January 31, 2019, 7:15am

Curious issue. So the type really isn’t in any of the referenced libraries. I’m going to have to investigate why, I did fix the message to be a lot better though.

JohnMoshakis · February 2, 2019, 11:45pm

Is this one fixed ? I see it mentioned in the change log but the bug bot hasnt replied saying its closed.

The reason Im wondering is that although Im no longer seeing the error Im getting these errors

E: Indirectly used type “System.Data.Common.DbConnection” is defined in an unreferenced assembly (netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51) [/Users/JohnMoshakis/Documents/develop/Echoes/Core/CarterDataWebApp/Repositories/AWSPostgresRepository.pas (62)]
E: Indirectly used type “System.Data.Common.DbConnection” is defined in an unreferenced assembly (netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51) [/Users/JohnMoshakis/Documents/develop/Echoes/Core/CarterDataWebApp/Repositories/AWSPostgresRepository.pas (76)]

If I add the assembly System.Data.Common then it builds so Im not sure if its a bug ?

Cheers,
John

ck · February 3, 2019, 7:52am

I fixed the error itself, but it will still fail because it can’t find the monitor type. I’ve got a research issue to see why it can’t be found in the first place.

JohnMoshakis · February 3, 2019, 4:54pm

Ok thanks.

The original example had my coding errors. Do you want the updated one it just has the indirectly used type issue.

mh · March 11, 2019, 4:34pm

I’m following up on this one, and I’m wondering of the logic of implicitly referencing Microsoft.ASPNETCore.App for an ASP.NET Core project is wring, and instead we need to reference Microsoft.NETCore.App, just as for a non-ASP project?

Can you check what there equivalent VC# project does, John?

mh · March 11, 2019, 4:41pm

Nevermind, no, dotnet also uses Microsoft.AspNetCore.App.

JohnMoshakis · March 11, 2019, 5:05pm

I think it does it via the deps.json

“targets”: {
“.NETCoreApp,Version=v2.1”: {
“mvccore/1.0.0”: {
“dependencies”: {
“Microsoft.AspNetCore.App”: “2.1.1”,
“Microsoft.NETCore.App”: “2.1.0”
},
“runtime”: {
“mvccore.dll”: {}
},
“compile”: {
“mvccore.dll”: {}
}
},

I think that’s why I get issues with Assembly missing on type

JohnMoshakis · March 11, 2019, 6:56pm

Are you looking into properly supporting asp.net core ?

mh · March 11, 2019, 7:35pm

that’s the idea. this SHOULD work as it is now. i don’t know why the Monitor type isn’t there.

JohnMoshakis · March 11, 2019, 8:03pm

Not that I know what I’m talking about

Does Microsoft.AspNetCore.App reference a different System assembly than Microsoft.NETCore.App ?

If thats the case can you redirect to the one in Microsoft.NETCore.App ?

mh · March 11, 2019, 8:18pm

Not really, Both full in System.Threading.dll, which according to the docs has the type, but according to ILSPy, the deliverable in the package does not :(.

But this gives me an idea: when Carlo is back, he should be able to check where the compiler does find the type when building a regular .NET Core app, and that might give us a clue.

JohnMoshakis · March 11, 2019, 8:20pm

At least for the other issues I had ie Assembly on Type it does. My hack was to move the code into a standard library.

mh · March 11, 2019, 8:27pm

.NET Core adds a lot more refs:

Adding .dll reference System.Threading.Overlapped.dll.
                     Adding .dll reference System.Threading.Tasks.Dataflow.dll.
                     Adding .dll reference System.Threading.Tasks.Extensions.dll.
                     Adding .dll reference System.Threading.Tasks.Parallel.dll.
                     Adding .dll reference System.Threading.Tasks.dll.
                     Adding .dll reference System.Threading.Thread.dll.
                     Adding .dll reference System.Threading.ThreadPool.dll.
                     Adding .dll reference System.Threading.Timer.dll.
                     Adding .dll reference System.Threading.dll.

these come from right inside microsoft.netcore.app:

/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.Overlapped.dll' for target 'Echoes'.
                     Reference 'System.Threading.Tasks.Dataflow' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.Tasks.Dataflow.dll' for target 'Echoes'.
                     Reference 'System.Threading.Tasks.Extensions' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.Tasks.Extensions.dll' for target 'Echoes'.
                     Reference 'System.Threading.Tasks.Parallel' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.Tasks.Parallel.dll' for target 'Echoes'.
                     Reference 'System.Threading.Tasks' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.Tasks.dll' for target 'Echoes'.
                     Reference 'System.Threading.Thread' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.Thread.dll' for target 'Echoes'.
                     Reference 'System.Threading.ThreadPool' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.ThreadPool.dll' for target 'Echoes'.
                     Reference 'System.Threading.Timer' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.Timer.dll' for target 'Echoes'.
                     Reference 'System.Threading' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.netcore.app/2.2.0/ref/netcoreapp2.2/System.Threading.dll' for target 'Echoes'.

ASP.NET Core instead uses the System.Threading NuGet package.

mh · March 11, 2019, 8:59pm

I find that also adding a reference to Microsoft.NetCore.App makes it build fine for me. (well, with a few other errors, but I assume thats specific to your test project).

Can you see if this works for you without any side effects? if so I’ll fix EBuild to make both references implicit for APS.NET Core for vNext.

JohnMoshakis · March 12, 2019, 1:00am

That works both at compile and runtime with this snippet of code in the main method

  var location := typeOf(Program).Assembly.Location;

Whats the importance of the Runtime setting in all of this ? Are the Runtime version and SDK version driven off the selected runtime ?

I tried sticking with Microsoft.Netcore.App and adding Microsoft.Aspnetcore.app as a reference. That also works at compile time but at runtime I get

Johns-Mac-mini:Debug JohnMoshakis$ dotnet ConsoleApplication2.dll
Error:
An assembly specified in the application dependencies manifest (ConsoleApplication2.deps.json) was not found:
package: ‘System.Net.Http’, version: ‘4.3.4’
path: ‘runtimes/unix/lib/netstandard1.6/System.Net.Http.dll’

I tried that because that appears to be the only way to control the version of aspnetcore.app

ck · June 20, 2019, 7:19am

This original issue seems to be fixed in fridays isue now too (the Monitor missing)

RemObjectsSoftware · June 20, 2019, 7:20am

bugs://81859 got closed with status fixed.