Making Nancy run on .NET Core

[jchannon]

Obviously we want to make Nancy run on .NET Core so we'll use this issue as the parent issue.

• Restructure repository to aid project.json port (Restructured repository #2154)
• Convert production projects to project.json (Port production projects to project.json #2155)
• Convert demo projects to project.json
• Convert test projects to project.json (this possibly involves upgrading xUnit to 2.1)
• Add dotnet5.3 (netstandard1.2) targets to run on .NET core (and beyond!)
• Revamp build infrastructure to build on .NET, Mono and .NET core, on both Linux and Windows (Travis and AppVeyor?)
• 🔥 all Ruby-related stuff
• 🔥 old .csprojs, packages.config, nuspec etc.

Please add items to this list or ask @NancyFx/most-valued-minions @NancyFx/owners to append it

[andrewcoll]

• Get Nancy compiling on dnx core (removing anything that causes build break for now)

[andrewcoll]

I ran Nancy.dll through the portability analyzer, I've uploaded the spreadsheet here:

http://1drv.ms/1G9OAMN

Lists all the references that are not supported in aspnet5 and an alternative in some cases. Most of the System.Type ones are for TinyIOC which we can ignore as there is already a coreclr version of that available.

[tugberkugurlu]

One other thing to consider would be to sit on top of the new routing system rather having a custom one. For example, MVC 6 today hooks into this routing system.

[phillip-haydon]

@tugberkugurlu you mean pass the routes from a module back to the middleware? Or move the routes out of the modules all together and use the middleware to point to routes?

[grumpydev]

We won't be replacing our routing, if people want to use the ASPNet stuff to do mapping that's fine, but that's no different to how we currently use OWIN (and without any of the IApplicationBuilder nonsense - bleh :))

[EliotJones]

I gave a go at cutting down some of the build errors but messed git up a bit in the process: https://github.com/EliotJones/NancyTest/tree/feature/core50 . For me this is building against DNXCore50 with only 200 errors but it might just be my environment, sorry if it's still broken for everyone else

[jchannon]

@awec where's that coreclr version of tinyioc you mention?

[janus007]

So... does this mean I can use this branch in my DNX 451 project?

[jchannon]

You can try but it's not complete

On Wednesday, 12 August 2015, janus007 [email protected] wrote:

So... does this mean I can use this branch in my DNX 451 project?

—
Reply to this email directly or view it on GitHub
#1959 (comment).

[masaeedu]

@janus007 I've been using the latest Nancy and Nancy.Owin, along with the UseOwin extension method available in the Microsoft.AspNet.Owin package, and things seem to have been running smoothly so far. I'll re-emphasize that this is DNX 451, i.e. running on the full CLR and probably won't work on CoreCLR. Here's what my Startup class looks like:

using Nancy;
using Nancy.Owin;
using Microsoft.AspNet.Builder;

class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        var nancy = NancyMiddleware.UseNancy(NancyConfiguration);

        // Give Nancy first crack at serving the request
        app.UseOwin(adder => adder.Invoke(nancy));

        // Add any other middleware you want
        app.UseDefaultFiles();
        app.UseStaticFiles();
    }

    private void NancyConfiguration(NancyOptions opts)
    {
        // Configure Nancy however you want
    }
}

[khellang]

@masaeedu You know that we provide an extension method for the AddMiddleware delegate in ASP.NET 5, so you can do

// Either
app.UseOwin(owin => owin.UseNancy(NancyConfiguration));

// Or
app.UseOwin().UseNancy(NancyConfiguration);

And you don't even need Nancy.Owin for it to work. It's in the core package.

[masaeedu]

@khellang Ah, I didn't realize there was a UseNancy for the "MidFunc eater" delegate. Apologies for any misinformation.

[tpluscode]

Hi. I've just created a bare-bone Nancy app in DNX 4.5.1 with a module in a separate class library. It turns out that Nancy cannot discover modules from that library, because the reference is actually not added until some code referenced. The typical way Nancy discovers stuff by inspecting all assemblies in bin also doesn't work, because apparently there is no bin folder, or is there?

Is there any way other than actually referencing some code explicitly? This breaks the feature I liked about Nancy, that I could just drop a dll in bin and it just works.

[khellang]

@tpluscode This is the same for all Nancy projects - DNX or not. Nancy won't scan assemblies not referencing Nancy.dll by default.
If you don't reference the dll or not using any Nancy code in your library at compile-time (which makes the compiler strip the reference), it won't be picked up by default.
We even added the [assembly: IncludeInNancyAssemblyScanning] attribute just for this scenario.

Also, there's no hardcoded path that Nancy scans. It looks at AppDomain.CurrentDomain.SetupInformation.ApplicationBase and AppDomain.CurrentDomain.SetupInformation.PrivateBinPath, so AFAIK this works on DNX451 as well 😄

[tpluscode]

@khellang AFAICT [assembly: IncludeInNancyAssemblyScanning] helps when a class library doesn't reference Nancy (or that assembly is removed at compilation) and not when that class library is removed. Is that right?

In my case the Nancy hosted with OWIN in a ASP.NET 5 app doesn't discover my module. ApplicationBase is the DNX path, so that won't help and it turns out that the PrivateBinPath is an empty string. Any ideas?

Also, here's a repro.

[khellang]

Hmm. When I think about it, I doubt anyone's actually tested this scenario. It's probably just been tested with modules in the same assembly as the host.
Until we get up and running with DNX's ILibraryManager, I think we'll have to find a workaround here.
I think you have to inject IApplicationEnvironment into your Startup and set PrivateBinPath to its ApplicationBasePath or something.

[khellang]

Some context; aspnet/dnx#1253

[Alxandr]

@khellang getting it to run with ILibraryManager should be really easy. Here's the entire MVC's implementation (really few LOCs): https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Core/Infrastructure/DefaultAssemblyProvider.cs

[khellang]

Absolutely. But there are some yaks that needs some shaving before we get to that point;
We're aiming to empty our PR/issue queue, ship 1.4, then start (continue) on 2.0, which will move to project.json, drop 4.0 etc.

[khellang]

One part of the problem is that Nancy's assembly scanning is static today, while ILibraryManager is instance based, so we have to adjust the assembly scanning a bit. See #1846 for context.

[danfma]

Hey guys, how is the work on this feature?

[khellang]

@danfma We're working on some stuff to unblock .NET core. net451 etc. should work fine.

[danfma]

Can I help with anything? I don't have much time but I can try to help with something.

[khellang]

The problem is that there's not enough work to do it concurrently. We'll just have to let @thecodejunkie finish #1846 after #2000 is done 😄 Thanks for offering your help! 👍

[danfma]

Ok!

[jchannon]

UPDATE : I ditched my branch as it got too big and we plan to move to dnx in smaller stages. At time of writing we already have a couple of PRs to change the repo structure and have csproj and project.json side by side in the short term

[RTodorov]

Hi guys,

Is someone still working on this? Can we help somehow?

http://www.ageofascent.com/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/

Looking forward to see Nancy doing it! ;)

[Yantrio]

looks like this issue is a bit old, we just got nancy compiling on the coreclr today (about 3 hours ago) and you can see our efforts over on the coreclr branch (issue #2220 tracked most of the issues)

@jchannon can we close this now?

[jchannon]

This is kind of a duplicate of #2220 so closing but if anyone is following check these out:

https://twitter.com/NancyFx/status/702825092418543616
https://twitter.com/jchannon/status/702835712224325632

[RTodorov]

Wow, that is great!! Nice timing! Are you planing to release a version anytime soon?

[jchannon]

Not at the moment. We plan to do a 2.0-alpha soon from master branch, then
once we have all of nancy projects eg/nancy testing, authentication etc
compiling I imagine we may do an alpha/beta release of that but this purely
guess work at the moment

On 25 February 2016 at 14:45, Renato Quinhoneiro Todorov <
[email protected]> wrote:

Wow, that is great!! Nice timing! Are you planing to release a version
anytime soon?

—
Reply to this email directly or view it on GitHub
#1959 (comment).

[peterblazejewicz]

@jchannon
What is the status of dotnet core at the moment? I'm trying to port Nancy.Demo.Hosting.Kestrel/Person.cs for RTM on generator-aspnet but I have problems (OS X/ dotent 1.0.0-preview2-003121)
Thanks!

[jchannon]

dotnet core is compiling on the master branch, we have no nuget package out
yet, we are working on getting our build script over to cake, once that is
done we can release a nuget package

On 26 June 2016 at 09:48, Peter Blazejewicz [email protected]
wrote:

@jchannon https://github.com/jchannon
What is the status of dotnet core at the moment? I'm trying to port
Nancy.Demo.Hosting.Kestrel/Person.cs for RTM on generator-aspnet but I
have problems (OS X/ dotent 1.0.0-preview2-003121)
Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1959 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAGapvOEMpUda46QSzN2J0mqUtvhvwUtks5qPjzvgaJpZM4E-PLI
.

[peterblazejewicz]

Thanks!

[a23o]

Hi guys!
How is the cake build going? Do you have a roadmap for the nuget package?
I appreciate your hard work.

Thx

[cemremengu]

@a23o already done :) checkout the latest barneyrubble release

[a23o]

Awesome!! Thank you.

[mrgrifon]

Thank you very much for the great work you.
I was able to run Nancy under .NET Core
But I am having a problems with Nancy.Hosting.Self

Package Nancy.Hosting.Self 2.0.0-barneyrubble is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Nancy.Hosting.Self 2.0.0-barneyrubble supports: net452 (.NETFramework,Version=v4.5.2)

As I can see from sources you already updated this package.

I am running .NET Core on Linux Ubuntu 14.04 LTS
Could you help me?

[phillip-haydon]

@mrgrifon You should use Kesteral hosting, please refer to https://github.com/NancyFx/Nancy/tree/master/samples/Nancy.Demo.Hosting.Kestrel

[erinxocon]

Will self hosting be implemented for .NET core, or is the plan to just use Kestral?

[khellang]

Kestrel is self-hosting. It's the default model for ASP.NET Core apps. Either using Kestrel, or WebListener.

[mmaguigan]

UseOwin seems to be missing from Kestrel in .NET Core...

[khellang]

UseOwin has never been a part of Kestrel. You need to install Microsoft.AspNetCore.Owin to get the UseOwin extension method.

[mmaguigan]

khellang, it's installed and is no longer present with .NET Core 2.0 preview 1.

EDIT: uhm, okay. I have a project we've been working actively on for the last five months and I upgraded to .NET Core 2.0 preview today and UseOwin was gone... apparently the package was removed in the process. Re-added it back in and all is well. Thanks, sometimes just takes another set of eyes I suppose ;)

[reddy6ue]

Thoroughly confused right now. So, is the netcore 2.0 port happening?

[fizxmike]

The thing I (probably we) love about Nancy.Hosting.Self is the MINIMAL boilerplate... That kestrel demo project is a nightmare for anyone getting started with dotnet core and Nancy IMHO. I don't mind switching to kestrel, just give us a minimalist example PLEASE!?

Right now, OWIN looks like the way to go. There is official documentation for hosting Nancy with OWIN (although no mention of dontenet core). And someone posted usable code snippets on this thread.

[fizxmike]

Nancy on Dotnet Core (OWIN + Kestrel)

Alright! Here is a little gift to anyone who wants to do this but couldn't find a good example.
The "key" is to use the clinteastwood preview on the nuget channel (there is also a NancyFX MyGet channel with a bleeding edge build of Nancy.Owin)
The catch is that the nancy builds are not for dotnet core, they are .NET framework, but dotnet core 2.0 has some invisible shim to allow imports of .NET Framework dlls, so... YMMV.
(please let me know if anything seems off)

HelloWorld.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <AssemblyName>HelloWorld</AssemblyName>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Hosting" Version="2.0.2" />
    <PackageReference Include="Microsoft.AspNetCore.Owin" Version="2.0.2" />
    <PackageReference Include="Microsoft.AspNetCore.Server.Kestrel" Version="2.0.2" />
    <PackageReference Include="Nancy" Version="2.0.0-clinteastwood" />
    <PackageReference Include="Nancy.Owin" Version="2.0.0-clinteastwood" />
  </ItemGroup>

</Project>

Program.cs

using System;
using Microsoft.AspNetCore.Hosting;

namespace HelloWorld
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }
    }
}

Startup.cs

using Nancy.Owin;
using Microsoft.AspNetCore.Owin;
using Microsoft.AspNetCore.Builder;

namespace HelloWorld
{
    public class Startup
    {
        public void Configure(IApplicationBuilder app)
        {
            app.UseOwin().UseNancy(NancyConfiguration);
        }

        private void NancyConfiguration(NancyOptions opts)
        {
            // Configure Nancy however you want
        }
    }
}

DefaultModule.cs

using Nancy;

namespace HelloWorld
{
     public sealed class DefaultModule : NancyModule
    {
        public Router()
        { 
            Get("/", _ => "Hello (dotnet core) World!");
        }
    }
}