AspNet MVC Core

[skorunka]

Hello,
is this compatible with MvcNet Core?
Thank you.

[mcintyre321]

Not yet. I plan to do it once core supports csproj.
On 4 Jul 2016 23:18, "Frantisek Skorunka" notifications@github.com wrote:

Hello,
is this compatible with MvcNet Core?
Thank you.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#151, or mute
the thread
https://github.com/notifications/unsubscribe/AAQ0-jlyaihmCJJv-WeUc9pye_bcQe6fks5qSXixgaJpZM4JEp9L
.

[mcintyre321]

I now plan to do this when I have time, as I now know how to do it! If anyone is interested, my other project FormFactory is now on core and can be used as a basis for the work.

[skorunka]

@mcintyre321 FF looks very good. Will give it a try, good job.

[Sohra]

I am currently using this in an ASP.NET Core MVC project targeting .NET 4.6.1 (since Core MVC runs on both .NET Core and the .NET Framework) and may be able to assist.... but I have little experience with GIT, have never submitted a pull request or anything like that.

There is also the question of how would you want to support ASP.NET Core MVC in this library? The NuGet package Microsoft.AspNetCore.Mvc targets both .NET 4.5.1 and .NET Standard 1.6 (for .NET Core support).

That gives some options...
Do we still want to support MVC 5? Most obvious option is a major version bump that replaces the MVC 5 reference with ASP.NET Core MVC, people upgrading to the new version must also upgrade to MVC Core if they were using this with an MVC 5 application. This library can then forget about MVC 5 and move on, if people need MVC 5 and this library they use an older version.

Or, two different NuGet packages could be maintained for this library - the original currently depends on MVC 5, but a second package could be maintained that depends on MVC Core. This gives consumers the choice of both MVC framework and target platform, and they can use every platform their chosen MVC framework supports.

Finally, we could attempt to support both MVC frameworks in the same NuGet package but the tradeoff is we must restrict the choice of MVC framework-target platform combinations consumers have. It's quite easy to set this up with the new xproj system, but I fear it may be considered an abomination by the masses. I'm using it for a new common library because it means projects that are built on ASP.NET Core MVC from the beginning get the latest and greatest, but older projects that are considerable size and may wish to benefit from the common library but I cannot afford to undertake upgrading the entire project to ASP.NET Core MVC yet, have a stepping stone - an upgrade path. While they target their older frameworks they can consume the new library with the older MVC framework. For example, if consumers of this library target .NET 4.5.1 they could use MVC 5 but if they target .NET Core they get MVC Core.... the restriction here is that you couldn't use the next version of MVC on .NET 4.5.1... in my particular use case, that's just fine, but MVC Core supports 4.5.1 and somebody else might wish to do this, and use this library....

What is the general feeling about these options?

Is this a request to support .NET Core? Or just ASP.NET Core targeting .NET Framework?
Ignoring .NET Core for the time being made consuming this library trivial for me, but upgrading it to support .NET Core is within my capability I believe.

[mcintyre321]

I think there will be plenty of people using MVC5 for the next few years, so two packages with a core library is best.

That's how I have done [FormFactory](https://github.com/mcintyre321/FormFactory} project

For .NET 4.51 with ASP MVC5 you install

• the core/shared FormFactory package
• a FormFactory.AspMvc package

For .NET Core/4.51 with ASP.NET Core you install

• the core/shared FormFactory package
• a web platform specific FormFactory.AspNetCore package

For this project I see the following

For .NET 4.51 with ASP MVC5 you would install

• the core/shared Mvc.JQuery.Datatables.Core (it would be better if I had called this common, but it's too late!)
• the ASP MVC5 specific Mvc.JQuery.Datatables package

For .NET Core/4.51 with ASP.NET Core you would install

• the core/shared Mvc.JQuery.Datatables.Core
• a new ASP.NET Core specific Mvc.JQuery.Datatables.AspNetCore package

[mcintyre321]

So I think that the way the work has to be done is this:

1. Convert the Mvc.JQuery.DataTables.Core to be a multi-targeted AspNet core project which supports both Standard and .NET 451
2. Update the existing .NET 451/MVC5 Mvc.JQuery.DataTables to reference the Mvc.JQuery.DataTables.Core project
3. Check that the Mvc.JQuery.Datatables.Example project works

At this point the project should be backward compatible still

4. Create a new Mvc.JQuery.DataTables.AspNetCore project, based off the Mvc.JQuery.DataTables project, which uses ASP.NET Core

5. Create a Mvc.JQuery.Datatables.Example.AspNetCore project, based off the other one and get it working. It's probably worth getting rid of the EntityFramework code in there as it won't be compatible.

It's a big job though!

[mcintyre321]

@Sohra I noticed you forked the project earlier, perhaps we are working on the same thing at the same time!

I've pushed a branch called vs2017 which has step 1, 2 and 3 done, and I've created empty projects for Mvc.JQuery.DataTables.AspNetCoreandMvc.JQuery.DataTables.Example.AspNetCore`

If you are working on this, and would be interested in carrying on the code from here, let me know here, or on gitter

[Sohra]

Yeah I had started porting Core to .NET Standard 1.6, but I'll abandon that now.

I was holding off installing 2017 until it went RTM, but I'll put the RC on my machine tonight and check out your branch. I'll evaluate how I might contribute after checking that out.

[Sohra]

I'm so stupid, I'm looking at the vs2017 branch on my fork instead of the latest in this repo -_-;;;

[Sohra]

Alright, I've done a little work in my fork. I'm basically just copying the MVC 5 example project into the MVC Core project and resolving the errors. It's a work in progress, I don't know if I will work as quickly as you desire, and I'm not much of a web developer to be perfectly honest.

[mcintyre321]

Brilliant, sounds like you're on the right track. Thanks for contributing!

…

On Thu, 23 Feb 2017 at 12:01, Sohra ***@***.***> wrote: Alright, I've done a little work in my fork. I'm basically just copying the MVC 5 example project into the MVC Core project and resolving the errors. It's a work in progress, I don't know if I will work as quickly as you desire, and I'm not much of a web developer to be perfectly honest. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#151 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQ0-oSwWAfPWQZMIQYoUxc0lYYO3RKhks5rfXTsgaJpZM4JEp9L> .

[Sohra]

@mcintyre321 Did your work break the MVC5 project's ability to find the embedded DataTables partial view by chance? I tried to run it to compare with ASP.NET Core version but it wasn't in a running state for me.

[mcintyre321]

I think maybe that was a bug and there are some commits on master that fix it? For some reason the views and assets were set as Content not Embedded Resources. Those commits might have happened after the migration branch was created.

…

On Sun, 5 Mar 2017 at 04:44, Sohra ***@***.***> wrote: @mcintyre321 <https://github.com/mcintyre321> Did your work break the MVC5 project's ability to find the embedded DataTables partial view by chance? I tried to run it to compare with ASP.NET Core version but it wasn't in a running state for me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#151 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQ0-qDO4WYpSiVykB0JUIE9a4KMfazcks5rij21gaJpZM4JEp9L> .

[mcintyre321]

Thanks to @Sohra who made several contributions, the vs2017 branch is in semi-working order. Not long now, need to

• get some resources to load in the example project
• make sure everything is idiomatic and easy for users to configure/install
• get appveyor/nuget working

[mcintyre321]

Just need to update the docs now....

[Sohra]

Been a bit slow getting around to checking this, but I've just noticed one problem - Mvc.JQuery.DataTypes.Common still depends on Microsoft.AspNet.Mvc under net451, which appears to take precedence over netstandard1.6 when I tried installing it into a net461 project using VS2017 and NuGet 4. I don't believe this reference is actually required anymore and simply removing it and reissuing the packages would be a suitable fix I think (but I haven't got around to any actual testing beside deleting the line locally and ensuring it still builds).

As it stands with Mvc.JQuery.DataTables.AspNetCore v1.5.19, if somebody wishes to use this with ASP.NET Core MVC on .NET Framework instead of .NET Core, they will also take a dependency on MVC 5 via the Common package.

[mcintyre321]

Ah I see the problem... the Common project shouldn't need to depend on MVC5 (and probably doesn't otherwise the standard build wouldn't work).

I'll update the package when I get a chance, probably have to be later this week though. I'm happy to pull in a PR to that effect also if you don't want to wait.

[mcintyre321]

OK that dependency has been removed from the Common project

[mcintyre321]

In light of the recent change that ASP.NET Core 2.0 won't run on NETfx I might remove the multitargeting to simplify things.