DotNetCore WebAPI on Linux Application Dependency Failures during hab svc start

Habitat Help
#1

We have a dotnet core web service that can run on a windows machine without any issues. We are trying to write a habitat plan to run in Linux but are running into the following error when it is running. We have the System.Data.SqlClient included in the NuGet references, so we are not sure why it cannot find it. We are also not sure where the *.deps.json comes from in this process.

This is the error that continually prints out while the service is started:
TravelerProfiles.default(SV): Starting service as user=hab, group=hab
TravelerProfiles.default(E): /hab/svc/TravelerProfiles/run: line 1: #!/bin/sh: not found
TravelerProfiles.default(O): Error:
TravelerProfiles.default(O): An assembly specified in the application dependencies manifest (TravelerProfiles.deps.json) was not found:
TravelerProfiles.default(O): package: ‘System.Data.SqlClient’, version: ‘4.4.3’
TravelerProfiles.default(O): path: ‘runtimes/unix/lib/netstandard2.0/System.Data.SqlClient.dll’
hab-launch(SV): Child for service ‘TravelerProfiles.default’ with PID 78 exited with code exit code: 140

#2

are you running a dotnet restore in your build?

#3

Hey Matt,
Yes, we are doing a restore in the build. I based our plan off the habitat-aspnet-sample.

I have been working with Chris Maher on this a bit and we were able to do a Docker build from the Visual Studio generated Docker file for Linux. It was able to build and run without a problem. We cannot get the plan to build and run.

#4

We are also trying to see if we can get it running in Core 2.1, but the core/dotnet-core-sdk doesn’t have 2.1 support. It only goes up to 2.0.3. Could we get that core package updated for Linux to support 2.1.5?
We are able to run both our 2.0 and 2.1 versions of this WebAPI on our local Windows dev machines and inside a Linux Docker container. Neither will run correctly with the current core/dotnet-core-sdk and core/dotnent-core

Also, you core/dotnet-core is running DotNetCore 2.1.4. Could that be upgraded to 2.1.5 as well?

#5

I had hoped to look into this today but was unable to get to it. I’ll be out most of next week and into the following week and will likely not get to submitting new dotnet versions soon. No obligation but if you did want to submit a PR to bump those, I’m happy to review.

#6

Sounds good. I will work with Chris Maher today and get those submitted.

#7

Chris was able to get the package updated to 2.1.403 for the core/dotnet-core-sdk. We also discovered in this process that the core/dotnet-core didn’t have the asp core runtime. So Chris created the core/dotnet-asp-core and we are working on testing that now. There should be pull requests for those now.

#8

We have gotten past this issue by going with DotNetCore 2.1.5 and Chris and I worked on getting the core/dotnet-asp-core package submitted. Since this was a web api, it needed those additional run-time components. All we have left to figure out now is accessing the site while the service is running.

#9

Just to close this out, @Defilan and I were able to get this working. I realized that we needed the Dotnet asp core runtime instead of just the dotnet core runtime to get the web api working. There were also some Kestrel things that needed to be tweaked to get the HTTPS working and finally realized we needed to use the HAB_DOCKER_OPTS="-p 5000:443" environment variable. @Defilan created the core/dotnet-asp-core plan that is now part of the core plans. @mwrock I would be happy to work up a sample app and plan that follows the pattern that we used to get this working.

#10

If that is easy for you to do and you could post the repo here that would be great!