Ensure that corehost works on Nano Server

analogrelay commented 8 years ago

We had some issues with building dnx on Nano Server. We need to verify that corehost will work fine on Nano Server (which only supports the OneCore APIs).

analogrelay commented 8 years ago

I think @schellap and @gkhanna79 own this now, right? This is definitely important for RTM since we expect ASP.NET applications to run on Nano Server. @moozzyk may have some insight from our own porting efforts for DNX.

/cc @piotrpMSFT

gkhanna79 commented 8 years ago

Yes, @schellap owns it. However, I am not sure if this can make RC2 but can be done for RTM. I will move this to RTM - let me know if anyone feels otherwise.

CC @leecow

guardrex commented 8 years ago

@anurse @Rick-Anderson @shirhatti Curious ... Does the .NET 5 on Nano doc also need to stay under-the-covers until RTM? https://github.com/aspnet/Docs/pull/894

analogrelay commented 8 years ago

My only concern with waiting for RTM is that DNX RC1 ran on Nano Server, so this would be a temporary regression of behavior since an ASP.NET app compiled with dotnet cli would not be guaranteed to run on Nano Server.

@DamianEdwards, @danroth27, @davidfowl and @glennc should probably be aware of that :)

/cc @victorhurdugaci @muratg @Eilon

DamianEdwards commented 8 years ago

We have customers running on Nano now so this would indeed be a regression for RC2. What is the hold up?

analogrelay commented 8 years ago

It's mostly just that we have a new host now (corehost rather than dnx) and we need to to ensure that it runs on Nano server.

gkhanna79 commented 8 years ago

This would require building the host against apisets so that it can work on Nano server. And since it will be linked against them, we need to have the right forwarder binaries in place.

The work is to ensure all of this works - especially on downlevel OS. It would have been awesome to see this issue earlier but it came our way just yesterday. We will see what can be done for RC2.

CC @Petermarcu

moozzyk commented 8 years ago

At the moment ASP.NET requires reverse forwarders to be installed on Nano.

gkhanna79 commented 8 years ago

If reverse forwarders are installed, then the host should work (since R-Forwarders are going to resolve Kernel32->API-*). Has someone on ASP.NET or Nano server tried using the host?

guardrex commented 8 years ago

Yes ... It's working with the Forwarders package. Which is what we have in the tutorial on this. I can rapidly respond to changes for the doc to match any changes teams make, and I can add a note at the head of the doc saying "works for RC1 only" if RC2 is a concern.

guardrex commented 8 years ago

... btw ... my test middleware app is RC2 current packages and runtime ... and it did work just this morning.

guardrex commented 8 years ago

... dotnet CLI changes ... no idea on that one ... which I think is what @anurse is referring to here.

analogrelay commented 8 years ago

Requiring the reverse forwarders is probably just fine, so if we need to do that, that's fine.

@moozzyk, @victorhurdugaci You guys have done nano server work before. Do you still have a VM set up using nano? My VM host doesn't use Hyper-V (because Docker) so I can't easily set one up. We just need someone to try running a dotnet-published app on Nano Server and see if it works :)

victorhurdugaci commented 8 years ago

When we convert MusicStore it will test Nano server too. We have a Nano CI agent for it

gkhanna79 commented 8 years ago

If reverse forwarders (and not APISet forwarders) are always going to be present on Nano server, then please try the test @anurse suggested above. It should just work without requiring any changes to the host. In that case, this issue is a no-op and can be closed (once confirmation comes through).

moozzyk commented 8 years ago

The requirement of having reverse loaders on Nano for ASP.NET 5 comes from http platform handler and libuv. I could imagine that in the future http plafrom handler will no longer require forwarders. Similarly libuv can be fixed (there are ~20 APIs that are not available in one core - most of which have *Ex counterparts that are present in onecore) - especially if http platform handler is fixed.

Also, not sure how much of a scenario it is but cli apps will likely won't work...

I would say leave this open to fix for post RTM.

guardrex commented 8 years ago

Also, not sure how much of a scenario it is but cli apps will likely won't work...

@moozzyk Curious why it will/might break for dotnet cli? ... just because if true, it blocks the release of the ".NET 5 on Nano Server" doc for quite a while.

guardrex commented 8 years ago

@moozzyk Nevermind. I'm off that doc now. Someone else is going to handle it.

moozzyk commented 8 years ago

@GuardRex In general native apps not against onecore.lib don't work without reverse forwarders and reverse forwarders are not installed on Nano by default (as opposed to e.g. win10 Iot Core).

guardrex commented 8 years ago

@moozzyk thx

Eilon commented 8 years ago

@gkhanna79 I can get someone on my team to test this. However, we're doing our big rename right now so the test won't happen until at least next week.

guardrex commented 8 years ago

@Eilon I'm trying to do a "non-team" test now. dotnet cli is fighting me a little bit, but I'll see if/when I get my dotnet cli cook'in if I can get my test proj running on Nano by the end of the day.

analogrelay commented 8 years ago

Cool. At this point a simple console app test would be enough I think. We already know that the ASP.NET managed code works on Nano, it's just the native host we're concerned about :)

guardrex commented 8 years ago

@anurse It's :dog:'in me a little on package sources, but I'll play with it when I get back. I'm actually going to try to get this meaty MVC app running, but I'll make a console app, too. I'm going out for a skate, but if you have a tip on these package sources not working, I'm all :ear: :ear: :ear:'s ...

capture

Does that

https://www.myget.org/F/dotnet-core/api/v3

... need to be in my NuGet.Config? or in VS NuGet package sources?

victorhurdugaci commented 8 years ago

Are you running restore on nano?

guardrex commented 8 years ago

No ... locally .. my win10 dev machine On Jan 21, 2016 11:37 AM, "Victor Hurdugaci" notifications@github.com wrote:

Are you running restore on nano?

— Reply to this email directly or view it on GitHub https://github.com/dotnet/cli/issues/468#issuecomment-173685056.

Eilon commented 8 years ago

CC @ryanbrandenburg who will try this out as well.

gkhanna79 commented 8 years ago

@Eilon Do you have a tentative timeframe to get this validated?

guardrex commented 8 years ago

Here is some good Nano news this morning. I have the console app running on Nano. There are few rough edges, but it worked out ...

capture

Setup

Used dotnew new to provide the console app, which was kept in a folder at c:\newproj locally.
Nano Server TP4 configured with Reverse Forwarders and IIS packages
Folder layout on the Nano: c:\testsite\wwwroot\web.config; c:\testsite\newproj\ for the app payload, which included the .exe file and all of the DLL's; and c:\testsite\logs to hold the HttpPlatformHandler logs and show if the console app is triggered properly (i.e., receive the console output)
web.config and project.json are below.
After getting the bits in the right spots on Nano and configuring IIS for the app at port 8000, I hit the site at the VM's IIS endpoint: http://<nano_DNS_address>.westus.cloudapp.azure.com:8000. There's no response in the browser, of course, but the console app tosses the Hello Log! output properly into the HttpPlatformHandler log as you can see above. :+1:

<configuration>
  <system.webServer>
    <handlers>
      <add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" 
          resourceType="Unspecified" />
    </handlers>
    <httpPlatform processPath="..\newproj\newproj.exe" arguments="" stdoutLogEnabled="true" 
        stdoutLogFile="..\logs\httpplatform" startupTimeLimit="3600"></httpPlatform>
  </system.webServer>
</configuration>

{
  "version": "1.0.0-*",
  "compilationOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "NETStandard.Library": "1.0.0-rc2-*"
  },
  "frameworks": {
      "dnxcore50": { }
  }
}

Pain Points

Had to use dnu restore via VS to get packages, which ended up in DNX packages and had to manually moved to the .nuget folder. Trying dotnet restore from the CL constantly throws NotFound 404's for package sources (e.g., NotFound https://api.nuget.org/v3-flatcontainer/netstandard.library/index.json).
dotnet compile --native throws a "The system cannot find the file specified", but dotnet publish does produce all of the outputs needed. I would love to get it all down to a single .exe.
Minor issue when I copied a new project payload to the Nano (I changed "Hello World!" to "Hello Log!") without stopping the AppPool first: It broke responsiveness (i.e., writing to the log); however, it didn't crash the AppPool. I had to stop the AppPool and restart it to get the new "Hello Log!" version of the app responsive. This isn't all that surprising really. Not stopping the AppPool when making app changes is a huge no-no when dealing with IIS.

@anurse Is this along the lines of what you're looking for? ... or are you asking here if the app can be manually run (outside of IIS/HttpPlatformHandler) on a Nano without the Reverse Forwarders packages? If you'd like that test, I'll give it a go. If so, let me know if there are package (or package sources) changes over what I just did.

analogrelay commented 8 years ago

This is fantastic! It sounds like the core issue (i.e. corehost, pun intended of course) is not going to be a big worry.

I would suggest we keep this issue open though, since ideally we should not require the reverse forwarders for corehost. That is not as high a priority for us though since we already needed the Reverse Forwarders to run Kestrel (since libuv is not built against the OneCore surface).

I won't speak totally for @DamianEdwards but I think requiring the reverse forwarders for RC2 would be fine with us. If we can make corehost work without the forwarders for RTM that would be cool though.

guardrex commented 8 years ago

@anurse ... Right. That's kind'a what I thought. I am sort of personally curious though if it will run without the Reverse Forwarders packages on there (just the console app ... not via IIS ... not via HttpPlatformHandler of course with libuv's requirement for Reverse Forwarders right now). I think I will do that test when I get back from errands today.

My next big one is going back to the MVC6 testing I was doing the other day. I nearly choked to death :skull: on package problems; however, just the work you cats did in the last few days has helped a lot.

Let me see if I can get a full IIS/HttpPlatformHandler MVC6 app working this evening. I have 17 bottles of cheap beer :beers: and several hours to kill, so it should be fun to see what happens ... and yes ... I'll prob be posting random YouTube music videos on JabbR while I work on this. Apologies in advance to @benaadams for that! Please don't BAN me Ben. :smile: I'll report back ...

DamianEdwards commented 8 years ago

I thought we built libuv against OneCore specifically for Kestrel? @moozzyk

https://github.com/aspnet/libuv-build/search?utf8=%E2%9C%93&q=onecore

guardrex commented 8 years ago

https://github.com/aspnet/Hosting/issues/539#issuecomment-167709309

moozzyk commented 8 years ago

@DamianEdwards @GuardRex No, libuv is not linked against OneCore - until libuv code is updated to not use APIs that are not part of OneCore it can't be done. I briefly looked at what needs to be changed to fix this and it looked like in most cases it should be easy but some would require more thought and I have not had a chance to spend more time on it.

In the libuv-build repo we built libuv differently than it is built in the libuv repo to avoid introducing another tool chain (gyp (which requires python) and/or autotools) and because the toolchain they use did not support ARM and OneCore (this is not a big deal at the moment - as I said above the code cannot be linked agains OneCore at the moment). I briefly looked

Also note that currently http platform handler currently requires reverse forwarders as well (though I heard they would like to lift this requirement eventually)

guardrex commented 8 years ago

@anurse Well, that didn't work out (bone stock Nano ... no Reverse Forwarders) ...

capture

There's nothing showing in Event Viewer when trying to execute the app. It crashes Hard, Fast, and Clean ... I think I have the title of my autobiography there! :smile:

analogrelay commented 8 years ago

I'd expect that. Even if you only use APIs available on Nano, you still have to link your app specially to work with the "OneCore" API set libraries in order to work on Nano without Forwarders. We don't do that (yet).

guardrex commented 8 years ago

@anurse Ok, that's cool.

I've gone back to trying to get the MVC6 test app running on Nano. So far, it's going as well as last time ... package issues ... like getting the AppContext package now. We'll see. I'm on JabbR "Rubber Duck" programming along and posting random '80's music videos and drinking a lot of cheap :beer:. We'll see how far I get this time with it.

guardrex commented 8 years ago

@anurse Not happenig bro. Package issues out the wazoo. I even dropped back to @davidfowl HelloMvc and it's choking on package references big time. I fix one ... then go headlong right into another one. I'll try again in a few days. Until then, the :beer: and the :cherries: are quite good!

cherries

guardrex commented 8 years ago

@anurse

I would suggest we keep this issue open though, since ideally we should not require the reverse forwarders for corehost.

I kept the Nano without Reverse Forwarders ... deallocated in Azure but ready to go. Let me know when it should work, and I'll bring that puppy back online and call for a full spread of photon torpedoes. :rocket:

gkhanna79 commented 8 years ago

Nano is built on OneCore and until all native components (libuv, corehost, etc) are built for OneCore, reverse forwarders will be required.

BTW, this maybe bigger than just CoreHost. To make CLI work on any OneCore based SKU, all native components used in CLI toolchain need to be identified and fixed. Next, CLI toolchain will need to carry APISet forwarders to allow it to run on downlevel OS.

I have filed https://github.com/dotnet/cli/issues/1008 to @piotrpMSFT to drive that, instead of this one which appears to have served its purpose to validate that corehost works on Nano with reverse forwarders. Once https://github.com/dotnet/cli/issues/1008 is addressed, reverse forwarders dependency for CLI can be removed.

Is there any other validation required on this issue aside validating corehost or can we close this issue?

analogrelay commented 8 years ago

At the moment, AFAIK, the only native component we use is the CoreCLR itself which is already compiled against APISets and includes the APISet forwarders on Windows.

Now that we have the other issue, I think we can close this one.

moozzyk commented 8 years ago

@anurse @gkhanna79 - if I have a native dll and I compiled it against OneCore should the package containing the dll also contain the api sets needed by this dll or should it rely on the ones that are shipped with CoreClr?

gkhanna79 commented 8 years ago

CoreCLR carries api-set forwarders for what it requires. A native binary, not associated with CoreCLR, may consume other APIs that CoreCLR does not and thus, cannot rely on CoreCLR to carry APISet forwarders for it.

I believe the path ahead should be to package all APISets forwarders in a package that satisfy CLI native dependencies's requirements. This package could be a superset of APISets package for CoreCLR or a different intersection altogether.

moozzyk commented 8 years ago

@gkhanna79 - yeah, packaging api sets should be fine. Otherwise if a package containing a dll would contain api sets that are used by CoreClr then during publish they would stomp on each other. Not sure if this is a big problem but having api sets in a package(s) could solve it.

gkhanna79 commented 8 years ago

Closing this based upon the discussion above.

ryanbrandenburg commented 8 years ago

Just to pile on the confirmation, I was also able to get @davidfowl 's HelloMvc project running by doing "dotnet publish" (dotnet version 1.0.0) on my local machine, copying that to the Nano server and running the exe. The server responded with a 200 and the expected content.

guardrex commented 8 years ago

Cross ref (ViewBag bug on Nano): https://github.com/aspnet/Mvc/issues/3991

schellap commented 8 years ago

Cc @pakrym See this:

Here is some good Nano news this morning. I have the console app running on Nano. There are few rough edges, but it worked out ...

victorhurdugaci commented 8 years ago

What's are the few rough edges? :)

guardrex commented 8 years ago

@victorhurdugaci @schellap If you're asking about .NET Core on Nano: The only reported delta between TP4 and TP5 is that in TP4 a packages folder was included with the preview that contained the Reverse Forwarders and IIS packages but the packages folder is not present in the TP5 distro. A dev reported to me that he had to obtain the packages manually. I have yet to confirm this, and I'm planning on running both of my test apps (portable and self-contained) on Nano later this week. I can ping you back here with the result if you like.

dotnet / sdk

Ensure that corehost works on Nano Server #4554

Setup

Pain Points