Code completion issues with Microsoft.ASPNetCore.App

Elements Fire
1

Hi,

The console app builds but code completion doesnt work anywhere.

09%20PM MVCWebApi.zip (70.7 KB)
Cheers
John

2

I’ll have a look. do the references show as resolved?

3

Reproduced, but this is odd: reference resolving fails with

D:          Available Versions of 'runtime.osx.10.10-x64.runtime.native.System.Security.Cryptography.Apple': 4.3.1, 4.3.0-preview1-24530-04, 4.3.0.
E:          Could not obtain file handle for file /Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/runtime.osx.10.10-x64.runtime.native.system.security.cryptography.apple/4.3.1/runtime.osx.10.10-x64.runtime.native.System.Security.Cryptography.Apple.nuspec

which is an odd error to give; its consistent;y the same file, even if I delete the package from cache manually and it gets redownloaded… And indeed, the file is set to “no access”.

4

The other problem I have is that I cant debug. Fire just seems to hang. I know you said you hadnt started on asp.net. If you want I can send you a sample.

5

only asp.net, or does regular core hang too?

6

Just asp.net.

I did a dotnet new mvc and ported some of it to Oxygene. It looked like it was accepting requests but I couldnt run it from Fire.

1 Like
7

CC works now, but this is insane: http://share.dwarfland.com/79692bdd171c

this is the tree of references used by your ASP.NET app after I disabled that it fills in duplicates (e.g. if three refs had the same dependencies, that subtree would should under all three, before. with that logic in place it virtually never finished resolving). 243 unique .dll references. crazy.

8

lol. I was going to complain that its really slow compiling, would that be why ? Is there a new build I can try with ?

9

Doing a new build now, but the fix is part EBuild part Fire, so I want to do a full Fire build for you, which takes a bit longer (ETA 25 minutes for 20190115-195237-elements-develop, and then I’ll build Fire with that.

Compile itself isn’t too bad (I’m surprised really, given the number of refs), but it’s the resolving thats slow, especially the first time, when most of the dependencies aren’t in the cache yet. Subsequent resolves should be faster (and building incrementally for code changes should also use the cached resolve, unless the project file itself changed, so that speeds it up more).

1 Like
10

Going up, ETA 2 minuets. You might need to hit the Clear Cache link.

11

thanks that fixes the issue.

12

Actually i can now also debug. I realized that I had forgotten to return something from a method

It looks to debug really nicely in Fire

~> Process HelloWorldWebApp started
~> Trying to debug PID 41399
Hosting environment: Production
Content root path: /
Now listening on: http://localhost:5030
Application started. Press Ctrl+C to shut down.
~> Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request starting HTTP/1.1 GET http://localhost:5030/
e[40me[32minfoe[39me[22me[49m: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
Request starting HTTP/1.1 GET http://localhost:5030/
~> Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request finished in 66.9265ms 200
e[40me[32minfoe[39me[22me[49m: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
Request finished in 66.9265ms 200
e[40me[32minfoe[39me[22me[49m: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
Request starting HTTP/1.1 GET http://localhost:5030/favicon.ico
~> Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request starting HTTP/1.1 GET http://localhost:5030/favicon.ico
e[40me[32minfoe[39me[22me[49m: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
Request finished in 10.3632ms 200
~> Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request finished in 10.3632ms 200

13

Cool.