New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASP.NET Core Support #62

Closed
kendaleiv opened this Issue Oct 21, 2015 · 23 comments

Comments

Projects
None yet
7 participants
@kendaleiv
Contributor

kendaleiv commented Oct 21, 2015

  • Support CoreCLR

@khalidabuhakmeh khalidabuhakmeh changed the title from Add ASP.NET vnext support to ASP.NET Core Support Jun 9, 2016

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Aug 11, 2016

Contributor

@khalidabuhakmeh I'm quite keen to port this .NET Core, so I had a bit of a crack at it last night. So far it's a pretty big shift however, as I've used the native .NET Core middleware rather than wrapping the previous Owin middleware.

Before I go any further, I wanted to check what your thoughts are about how it should proceed. I think a separate Stuntman.AspNetCore (or similar) package will be necessary, the question is how to keep everything properly factored.

We could split the Core project in to 3, the base Core project, the 4.5 package, and .NET Core package, with the latter 2 depending on the base Core project. However it seems a bit overkill for people to need 2 packages when the base Core project will literally only have a few classes in it.

Instead, I'm leaning toward just 2 projects with a bit of duplication + 2 separate test projects, separate samples etc.

But in that case, would it just be easier/clearer to split the core version out into a separate repo completely, which would probably simplify builds, packaging etc.

Contributor

andrewlock commented Aug 11, 2016

@khalidabuhakmeh I'm quite keen to port this .NET Core, so I had a bit of a crack at it last night. So far it's a pretty big shift however, as I've used the native .NET Core middleware rather than wrapping the previous Owin middleware.

Before I go any further, I wanted to check what your thoughts are about how it should proceed. I think a separate Stuntman.AspNetCore (or similar) package will be necessary, the question is how to keep everything properly factored.

We could split the Core project in to 3, the base Core project, the 4.5 package, and .NET Core package, with the latter 2 depending on the base Core project. However it seems a bit overkill for people to need 2 packages when the base Core project will literally only have a few classes in it.

Instead, I'm leaning toward just 2 projects with a bit of duplication + 2 separate test projects, separate samples etc.

But in that case, would it just be easier/clearer to split the core version out into a separate repo completely, which would probably simplify builds, packaging etc.

@khalidabuhakmeh

This comment has been minimized.

Show comment
Hide comment
@khalidabuhakmeh

khalidabuhakmeh Aug 12, 2016

Member

@andrewlock first of all, thanks for checking out stuntman. We love the idea of others taking an interest in our OSS projects.

Before I go any further, I wanted to check what your thoughts are about how it should proceed. I think a separate Stuntman.AspNetCore (or similar) package will be necessary, the question is how to keep everything properly factored.

Yes we have looked at porting during RC2 and we would like to support both the current .NET infrastructure (OWIN) and the new .NET Core infrastructure (IApplicationBuilder). This means two packages on Nuget.

We could split the Core project in to 3, the base Core project, the 4.5 package, and .NET Core package, with the latter 2 depending on the base Core project. However it seems a bit overkill for people to need 2 packages when the base Core project will literally only have a few classes in it.

That is one option, but we could also use compiler directives to achieve the same thing. Its not as pretty, but would reduce the number of projects.

Instead, I'm leaning toward just 2 projects with a bit of duplication + 2 separate test projects, separate samples etc.

I would prefer we convert the projects over to the new xproj setup and utilize the new project.json stuff and just have the minimal amount of projects required. Additionally, when it comes to samples we can have one sample project, since ASP.NET Core still supports OWIN (with a lot of hoop jumping), we can use the same web application with two diverging paths: /netcore/_stuntman and /owin/_stuntman. We would just have to register it twice in the sample.

But in that case, would it just be easier/clearer to split the core version out into a separate repo completely, which would probably simplify builds, packaging etc.

I don't want a separate repository because that would mean duplicating wiki, documentation, etc.. I think that is out of the question for me.

Member

khalidabuhakmeh commented Aug 12, 2016

@andrewlock first of all, thanks for checking out stuntman. We love the idea of others taking an interest in our OSS projects.

Before I go any further, I wanted to check what your thoughts are about how it should proceed. I think a separate Stuntman.AspNetCore (or similar) package will be necessary, the question is how to keep everything properly factored.

Yes we have looked at porting during RC2 and we would like to support both the current .NET infrastructure (OWIN) and the new .NET Core infrastructure (IApplicationBuilder). This means two packages on Nuget.

We could split the Core project in to 3, the base Core project, the 4.5 package, and .NET Core package, with the latter 2 depending on the base Core project. However it seems a bit overkill for people to need 2 packages when the base Core project will literally only have a few classes in it.

That is one option, but we could also use compiler directives to achieve the same thing. Its not as pretty, but would reduce the number of projects.

Instead, I'm leaning toward just 2 projects with a bit of duplication + 2 separate test projects, separate samples etc.

I would prefer we convert the projects over to the new xproj setup and utilize the new project.json stuff and just have the minimal amount of projects required. Additionally, when it comes to samples we can have one sample project, since ASP.NET Core still supports OWIN (with a lot of hoop jumping), we can use the same web application with two diverging paths: /netcore/_stuntman and /owin/_stuntman. We would just have to register it twice in the sample.

But in that case, would it just be easier/clearer to split the core version out into a separate repo completely, which would probably simplify builds, packaging etc.

I don't want a separate repository because that would mean duplicating wiki, documentation, etc.. I think that is out of the question for me.

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Aug 15, 2016

Contributor

That all makes sense to me apart from the desire to have two packages on NuGet but potentially only one project (with compiler directives) for the actual project.

It seems like either having a single multi-targeted project and single nuget package, or two of each would be an easier way to go? I think the single project/package should be doable and probably makes the most sense.

And totally agree, duplicating the repo is overkill, don't know why I suggested it 😉

Contributor

andrewlock commented Aug 15, 2016

That all makes sense to me apart from the desire to have two packages on NuGet but potentially only one project (with compiler directives) for the actual project.

It seems like either having a single multi-targeted project and single nuget package, or two of each would be an easier way to go? I think the single project/package should be doable and probably makes the most sense.

And totally agree, duplicating the repo is overkill, don't know why I suggested it 😉

@khalidabuhakmeh

This comment has been minimized.

Show comment
Hide comment
@khalidabuhakmeh

khalidabuhakmeh Aug 15, 2016

Member

@andrewlock I'm not sure one package is possible because the issue is you don't know what version of ASP.NET you are targeting, you only know the .NET version you are targeting. You can still build on top of the new infrastructure with the full .NET 4.6+ and use the IApplicationBuilder interface. Conversely, you could use the OWIN version with ASP.NET Core. The two (three) packages approach would delineate between the OWIN interface and the ASP.NET Core interface.

  • Stuntman
  • Stuntman.AspNetCore
  • Stuntman.OWIN

Where Stuntman could be versioned up to switch to a particular interface by default.

Nuget Version 1.0

  • Stuntman -> Stuntman.OWIN
  • Stuntman.OWIN -> Stuntman.OWIN
  • Stuntman.AspNetCore -> Stuntman.AspNetCore

Nuget Version 2.0

  • Stuntman -> Stuntman.AspNetCore
  • Stuntman.OWIN -> Stuntman.OWIN
  • Stuntman.AspNetCore -> Stuntman.AspNetCore

Ultimately, both packages would be versioned to the same number via SemVer.

This is just a "off the cuff" idea, and feedback is appreciated.

@kendaleiv @billboga @jrusbatch

Member

khalidabuhakmeh commented Aug 15, 2016

@andrewlock I'm not sure one package is possible because the issue is you don't know what version of ASP.NET you are targeting, you only know the .NET version you are targeting. You can still build on top of the new infrastructure with the full .NET 4.6+ and use the IApplicationBuilder interface. Conversely, you could use the OWIN version with ASP.NET Core. The two (three) packages approach would delineate between the OWIN interface and the ASP.NET Core interface.

  • Stuntman
  • Stuntman.AspNetCore
  • Stuntman.OWIN

Where Stuntman could be versioned up to switch to a particular interface by default.

Nuget Version 1.0

  • Stuntman -> Stuntman.OWIN
  • Stuntman.OWIN -> Stuntman.OWIN
  • Stuntman.AspNetCore -> Stuntman.AspNetCore

Nuget Version 2.0

  • Stuntman -> Stuntman.AspNetCore
  • Stuntman.OWIN -> Stuntman.OWIN
  • Stuntman.AspNetCore -> Stuntman.AspNetCore

Ultimately, both packages would be versioned to the same number via SemVer.

This is just a "off the cuff" idea, and feedback is appreciated.

@kendaleiv @billboga @jrusbatch

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Aug 17, 2016

Contributor

@khalidabuhakmeh Ah, of course, I was thinking of it as 2 distinct targets - .NET 4.5 and OWIN or .NET Core and ASP.NET Core - instead of the combination of 4 we have in reality.

So, just to clarify, to support that combination we would need 3 'Main' projects

  • Stuntman - currently named Core in the solution, which could contain all the core classes from the current project, targeting both .NET 4.6 and .NET Core
  • Stuntman.OWIN - would contain the existing IAppBuilderExtensions class, targeting both .NET 4.6 and .NET Core
  • Stuntman.AspNetCore - which would contain a new implementation, IApplicationBuilderExtensions designed to work with ASP.NET Core, and targeting .NET 4.6 and .NET Core.

I think that should work pretty well, if I have understood you correctly there? If so then I think the upgrade route is pretty clear:

  • Convert to xproj with existing code base, target NET 4.X and .NET Core
  • Split Core project into Stuntman.Core and Stuntman.OWIN
  • Add Stuntman.AspNetCore project

In terms of having a single sample project demonstrating both OWIN and ASP.NET Core, that would be nice to keep all in one project, but I feel like it may be more confusing for people wanting to actually use the package. It might not be obvious to some that it's an either/or thing.

Contributor

andrewlock commented Aug 17, 2016

@khalidabuhakmeh Ah, of course, I was thinking of it as 2 distinct targets - .NET 4.5 and OWIN or .NET Core and ASP.NET Core - instead of the combination of 4 we have in reality.

So, just to clarify, to support that combination we would need 3 'Main' projects

  • Stuntman - currently named Core in the solution, which could contain all the core classes from the current project, targeting both .NET 4.6 and .NET Core
  • Stuntman.OWIN - would contain the existing IAppBuilderExtensions class, targeting both .NET 4.6 and .NET Core
  • Stuntman.AspNetCore - which would contain a new implementation, IApplicationBuilderExtensions designed to work with ASP.NET Core, and targeting .NET 4.6 and .NET Core.

I think that should work pretty well, if I have understood you correctly there? If so then I think the upgrade route is pretty clear:

  • Convert to xproj with existing code base, target NET 4.X and .NET Core
  • Split Core project into Stuntman.Core and Stuntman.OWIN
  • Add Stuntman.AspNetCore project

In terms of having a single sample project demonstrating both OWIN and ASP.NET Core, that would be nice to keep all in one project, but I feel like it may be more confusing for people wanting to actually use the package. It might not be obvious to some that it's an either/or thing.

@kendaleiv

This comment has been minimized.

Show comment
Hide comment
@kendaleiv

kendaleiv Aug 17, 2016

Contributor

It would be nice to keep a single NuGet package, rather than have different one's targeting OWIN and ASP.NET Core.

Is that a possibility?

Contributor

kendaleiv commented Aug 17, 2016

It would be nice to keep a single NuGet package, rather than have different one's targeting OWIN and ASP.NET Core.

Is that a possibility?

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Aug 17, 2016

Contributor

You could, yeah, but I think by definition that would require you to pull in dependencies for both OWIN and ASP.NET Core.

If you're using OWIN with ASP.NET 4.X or using ASP.NET Core like usual, then you're going to have a load of unneeded dependencies you need to pull into your application that you're not actually using.

Contributor

andrewlock commented Aug 17, 2016

You could, yeah, but I think by definition that would require you to pull in dependencies for both OWIN and ASP.NET Core.

If you're using OWIN with ASP.NET 4.X or using ASP.NET Core like usual, then you're going to have a load of unneeded dependencies you need to pull into your application that you're not actually using.

@kendaleiv

This comment has been minimized.

Show comment
Hide comment
@kendaleiv

kendaleiv Aug 17, 2016

Contributor

Perhaps there's a way to create a single package and only bring in the dependencies the target needs (depending if it's targeting ASP.NET Core or not).

Looking at https://blogs.msdn.microsoft.com/cesardelatorre/2016/06/28/running-net-core-apps-on-multiple-frameworks-and-what-the-target-framework-monikers-tfms-are-about/ it looks like this might be possible with "imports" in project.json per the second summary bullet -- but, isn't that going away?

Although, maybe that doesn't work if you're constructing a NuGet package? 😃

Contributor

kendaleiv commented Aug 17, 2016

Perhaps there's a way to create a single package and only bring in the dependencies the target needs (depending if it's targeting ASP.NET Core or not).

Looking at https://blogs.msdn.microsoft.com/cesardelatorre/2016/06/28/running-net-core-apps-on-multiple-frameworks-and-what-the-target-framework-monikers-tfms-are-about/ it looks like this might be possible with "imports" in project.json per the second summary bullet -- but, isn't that going away?

Although, maybe that doesn't work if you're constructing a NuGet package? 😃

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Aug 17, 2016

Contributor

While that works for targeting both .NET 4.X and .NET Core, I don't think there's a way to target 'traditional' ASP.NET vs ASP.NET Core (the web framework as opposed to the underlying target framework). ASP.NET Core is just a nuget package added to your .NET console app after all.

Contributor

andrewlock commented Aug 17, 2016

While that works for targeting both .NET 4.X and .NET Core, I don't think there's a way to target 'traditional' ASP.NET vs ASP.NET Core (the web framework as opposed to the underlying target framework). ASP.NET Core is just a nuget package added to your .NET console app after all.

@kdaveid

This comment has been minimized.

Show comment
Hide comment
@kdaveid

kdaveid Sep 21, 2016

It is possible to target full framework (.NET 4.x) and Core framework in one single nuget package.

Check out this example of a working nuspec for IdentityModel (which is a library consumed by IdentityServer).

kdaveid commented Sep 21, 2016

It is possible to target full framework (.NET 4.x) and Core framework in one single nuget package.

Check out this example of a working nuspec for IdentityModel (which is a library consumed by IdentityServer).

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 21, 2016

Contributor

Hi @kdaveid, yep that's definitely possible, the reason for 2 packages is to split out the OWIN middleware implementation vs the ASP.NET Core middleware. Both of those packages would support both Full and Core frameworks.

Contributor

andrewlock commented Sep 21, 2016

Hi @kdaveid, yep that's definitely possible, the reason for 2 packages is to split out the OWIN middleware implementation vs the ASP.NET Core middleware. Both of those packages would support both Full and Core frameworks.

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 21, 2016

Contributor

@khalidabuhakmeh, I've been running into some issues trying to get the OWIN version running on ASP.NET Core. Although you can do that using the Microsoft.AspNetCore.Owin package, it still doesn't support the OWIN IAppBuilder, it just directly wraps a Func<IDictionary<string, object>, Task>, which is causing me some pain!

I can't currently see an easy way to support both approaches, so I'm wondering if it's worth the effort? How many people are really going to use the OWIN wrapper on ASP.NET Core when there is a native version available, and OWIN is actively discouraged in that setting?

That way we would have

  • Stuntman.OWIN -> OWIN implementation, identical current samples (global.asax etc), Full framework
  • Stuntman.AspNetCore -> ASP.NET Core implementation, similar samples but ASP.NET Core, .NET Core + Full Framework.
Contributor

andrewlock commented Sep 21, 2016

@khalidabuhakmeh, I've been running into some issues trying to get the OWIN version running on ASP.NET Core. Although you can do that using the Microsoft.AspNetCore.Owin package, it still doesn't support the OWIN IAppBuilder, it just directly wraps a Func<IDictionary<string, object>, Task>, which is causing me some pain!

I can't currently see an easy way to support both approaches, so I'm wondering if it's worth the effort? How many people are really going to use the OWIN wrapper on ASP.NET Core when there is a native version available, and OWIN is actively discouraged in that setting?

That way we would have

  • Stuntman.OWIN -> OWIN implementation, identical current samples (global.asax etc), Full framework
  • Stuntman.AspNetCore -> ASP.NET Core implementation, similar samples but ASP.NET Core, .NET Core + Full Framework.
@khalidabuhakmeh

This comment has been minimized.

Show comment
Hide comment
@khalidabuhakmeh

khalidabuhakmeh Sep 22, 2016

Member

Hello Andrew,

How many people are really going to use the OWIN wrapper on ASP.NET Core when there is a native version available, and OWIN is actively discouraged in that setting?

Yeah I wouldn't worry about supporting OWIN in ASP.NET Core just because that is something we'll probably be away from in the next year or two.

When you say, Owin Implementation and ASP.NET Core, I'd like the majority of the code to be shared as much as possible. So that any new feature would make its way into both packages.

Member

khalidabuhakmeh commented Sep 22, 2016

Hello Andrew,

How many people are really going to use the OWIN wrapper on ASP.NET Core when there is a native version available, and OWIN is actively discouraged in that setting?

Yeah I wouldn't worry about supporting OWIN in ASP.NET Core just because that is something we'll probably be away from in the next year or two.

When you say, Owin Implementation and ASP.NET Core, I'd like the majority of the code to be shared as much as possible. So that any new feature would make its way into both packages.

@xt0rted

This comment has been minimized.

Show comment
Hide comment
@xt0rted

xt0rted Sep 22, 2016

You could use a Shared Project for anything that belongs in both projects. That functions like a class library but compiles as if it was in the project so there's no extra dll.

xt0rted commented Sep 22, 2016

You could use a Shared Project for anything that belongs in both projects. That functions like a class library but compiles as if it was in the project so there's no extra dll.

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 22, 2016

Contributor

Cool, sounds good.

Unfortunately it looks like shared projects aren't supported with xproj, but we should be able to achieve something similar using project.json (see here).

Contributor

andrewlock commented Sep 22, 2016

Cool, sounds good.

Unfortunately it looks like shared projects aren't supported with xproj, but we should be able to achieve something similar using project.json (see here).

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 22, 2016

Contributor

More pain - I can't see a way of creating a global.asax based project that uses xproj, and we cannot reference a xproj-based projects from a global.asax based project that uses csproj.

Which means converting the OWIN pipeline Core project to xproj causes more problems than it solves.

I'm struggling to find a solution to the problem to be honest. I started down the root of keeping the current sln as-it and just adding the additional projects, but the Compile/include approach linked above using project.json doesn't work that well. The files aren't shown in the solution, they're just packaged in at build time, so you don't get any intellisense when working with them.

The actual conversion to ASP.NET Core isn't that tricky from what I've played with, it's just trying to keep the OWIN version intact that's causing the problems.. May have to bow out until the tooling improves/evolves and we get the ability to cross reference csproj/xproj more easily, sorry 😞

Contributor

andrewlock commented Sep 22, 2016

More pain - I can't see a way of creating a global.asax based project that uses xproj, and we cannot reference a xproj-based projects from a global.asax based project that uses csproj.

Which means converting the OWIN pipeline Core project to xproj causes more problems than it solves.

I'm struggling to find a solution to the problem to be honest. I started down the root of keeping the current sln as-it and just adding the additional projects, but the Compile/include approach linked above using project.json doesn't work that well. The files aren't shown in the solution, they're just packaged in at build time, so you don't get any intellisense when working with them.

The actual conversion to ASP.NET Core isn't that tricky from what I've played with, it's just trying to keep the OWIN version intact that's causing the problems.. May have to bow out until the tooling improves/evolves and we get the ability to cross reference csproj/xproj more easily, sorry 😞

@khalidabuhakmeh

This comment has been minimized.

Show comment
Hide comment
@khalidabuhakmeh

khalidabuhakmeh Sep 22, 2016

Member

Hey could you submit a [WIP] PR so we can see what problems you are running into?

Member

khalidabuhakmeh commented Sep 22, 2016

Hey could you submit a [WIP] PR so we can see what problems you are running into?

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 22, 2016

Contributor

Sure, it's in #126

Contributor

andrewlock commented Sep 22, 2016

Sure, it's in #126

@jrusbatch

This comment has been minimized.

Show comment
Hide comment
@jrusbatch

jrusbatch Sep 22, 2016

Contributor

@andrewlock I think you're on the right path. Perhaps we could use Automapper as an example, and add common files to both projects as links instead of via a shared project?

Contributor

jrusbatch commented Sep 22, 2016

@andrewlock I think you're on the right path. Perhaps we could use Automapper as an example, and add common files to both projects as links instead of via a shared project?

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 22, 2016

Contributor

The trouble with links in the xproj project is the files don't show in the solution, unlike the csproj style linked files... It will work, but it will mean the projects are no fun to work with when you start having to add compiler directives in etc for errors that you can't see until build time!

Having said that, I'll fire up the AutoMapper repo in the morning and check out how they do it in case I'm missing something obvious.

Contributor

andrewlock commented Sep 22, 2016

The trouble with links in the xproj project is the files don't show in the solution, unlike the csproj style linked files... It will work, but it will mean the projects are no fun to work with when you start having to add compiler directives in etc for errors that you can't see until build time!

Having said that, I'll fire up the AutoMapper repo in the morning and check out how they do it in case I'm missing something obvious.

@khalidabuhakmeh

This comment has been minimized.

Show comment
Hide comment
@khalidabuhakmeh

khalidabuhakmeh Sep 24, 2016

Member

We could add the files under a solution folder so they are visible inside visual studio?

Member

khalidabuhakmeh commented Sep 24, 2016

We could add the files under a solution folder so they are visible inside visual studio?

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 24, 2016

Contributor

We could, but they still wouldn't show in the xproj project, so I don't think you would get intellisense etc.

Just had a thought actually, we leave the owin project as a csproj, and we move the files to the aspnetcore xproj project.

That way the aspnetcore project is just a normal xproj project (no project.json includes) , so you get proper intellisense, compiler directive support etc.

We can that add the same files as links to the csproj owin project as @jrusbatch suggested which should work well. That should do the trick! 😄

Contributor

andrewlock commented Sep 24, 2016

We could, but they still wouldn't show in the xproj project, so I don't think you would get intellisense etc.

Just had a thought actually, we leave the owin project as a csproj, and we move the files to the aspnetcore xproj project.

That way the aspnetcore project is just a normal xproj project (no project.json includes) , so you get proper intellisense, compiler directive support etc.

We can that add the same files as links to the csproj owin project as @jrusbatch suggested which should work well. That should do the trick! 😄

@andrewlock

This comment has been minimized.

Show comment
Hide comment
@andrewlock

andrewlock Sep 27, 2016

Contributor

I've just pushed up a new branch which I think is a good start on the ASP.NET Core support. It doesn't have all the build or package steps sorted yet, but the Core project is converted, the test project is converted, and there are 2 sample applications. Functionally everything seems to work as expected😄

Contributor

andrewlock commented Sep 27, 2016

I've just pushed up a new branch which I think is a good start on the ASP.NET Core support. It doesn't have all the build or package steps sorted yet, but the Core project is converted, the test project is converted, and there are 2 sample applications. Functionally everything seems to work as expected😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment