Publish .NETCore 2 API and host on IIS - asp.net

Question

I've created a .net Core 2 API and published it to the server.
The file structure looks very odd compared to a normal .Net MVC structure
Normal Structure I am familiar with
And this is the structure of the deployed .NET CORE 2 API
Now if I just try and convert that folder to an application like a normal ASP.NET app, it doesn't work.
I've installed the .NET Core Windows Server Hosting bundle on the server, but I'm still missing something.
Where do you add this code to enable IISIntegration ?
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.Build();

Answer 1

That code goes in Program.cs, but it's the default, so you should already be fine there.
The ASP.NET Core file structure is different than MVC 5, but it all pretty much works the same, once you've installed the .NET Core Hosting Runtime. You drop the published files in a directory on the web server. Then, you set up a site in IIS to use that directory. The only thing slightly different is that you need to edit the App Pool and set it to "No Managed Code", instead of a particular .NET runtime. Other than that, it should all just work.
That said, if your screenshot is a complete listing of the files, then you do seem to be missing some stuff. It's possible the publishing process failed at some point. Try to republish.
Background
The way ASP.NET Core works is fundamentally different than previous ASP.NET web applications. Whereas you used to have all the HTTP modules and such coming from the monolithic .NET Runtime installed on the machine, ASP.NET Core apps are completely self-contained. A Core app is in fact merely a console application. In an IIS setup, the actual web server is Kestrel, which either bundled into the Core app or available from the .NET Core runtime. IIS works as a reverse proxy. Handing off requests to Kestrel and then returning the responses it gets from Kestrel (hence the "No Managed Code"). With IIS deployment your app is a DLL, but it can also be entirely self-contained and deployed as an executable. The point is that, yes, the file structure and such is very different because it fundamentally works in a different way.