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

(JohnMoshakis) #1

Hi,

Im getting an internal error while building a test app.

CarterDataWebApp.zip (73.7 KB)

              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

(RemObjects) #2

Thanks, logged as bugs://81859

(Carlo Kok) #3

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.

1 Like
(JohnMoshakis) #4

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

(Carlo Kok) #5

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) #6

Ok thanks.

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

(marc hoffman) #7

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?

(marc hoffman) #8

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

(JohnMoshakis) #9

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) #10

Are you looking into properly supporting asp.net core ?

(marc hoffman) #11

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

(JohnMoshakis) #12

Not that I know what I’m talking about :slight_smile:

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 ?

(marc hoffman) #13

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) #14

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.

(marc hoffman) #15

.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.

(marc hoffman) #16

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) #17

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