Mvc: Discussion: Microsoft.AspNetCore.Mvc.Dnx is required to allow Mvc in RC2 to work with Dnx

[pranavkm]

Discussion for https://github.com/aspnet/Announcements/issues/154

As part of our recent migration, we broke compatibility with DNX in Mvc. This prevents controller and view component discovery from working correctly and view compilation to fail in our latest sources and packages on the aspnetcidev \ aspnetvnext feeds. To address this issue, we've published Microsoft.AspNetCore.Mvc.Dnx to https://www.myget.org/F/aspnetcidev feed that would allow Mvc to continue working with DNX until we've tooling support for dotnet-cli tools.

To use this package:

1. Add the https://www.myget.org/F/aspnetcidev feed to your sources.
2. Add Microsoft.AspNetCore.Mvc.Dnx to your project.json.
3. In your startup under ConfigureServices add a call to AddMvcDnx:

C# public void ConfigureServices(IServiceCollection services) { ... services.AddMvc(); services.AddMvcDnx(); .... }

[kevinchalet]

@pranavkm quick question: was targeting dnx451 instead of net451 mandatory?

[pranavkm]

Apparently not. I was under the impression Microsoft.Extensions.PlatformAbstractions.Dnx targeted dnx451 which it clearly doesn't. I could change it if there's a need to do so.

[kevinchalet]

Yeah, that would be awesome :+1:

I had planned to submit a PR, but I'm unable to compile MVC locally (and I didn't want to submit something if I wasn't sure it compiled fine)

[pranavkm]

Done as part of https://github.com/aspnet/Mvc/commit/54bc9a7327bc8986abf10a5743c9f91e5a1387cd

[davidfowl]

@pranavkm Can we make it so you only have to call a single thing?

[pranavkm]

@davidfowl, it'd make it easier to remove it once we stop supporting DNX.

[anfomin]

Can you upload latest packages, including Microsoft.AspNetCore.Mvc.Dnx, to https://www.myget.org/gallery/aspnetvnext? AspNetCore already there...

[pranavkm]

Our signed builds had issues over the weekend. It'll get to the aspnetvnext feed once that is sorted out.

[aL3891]

This wont be needed post RC2 right?

[pranavkm]

@aL3891 that is correct. My guess is we would not publish this package to nuget.org as part of the RC2 release since dotnet tooling support would be available by that time.

[tstar]

I can not install package "Microsoft.AspNetCore.Mvc.Dnx": "1.0.0-rc2-20019". I get an error:
Restore failed
More than one runtime.json file has declared imports for 'win7-x86'
Parameter name: runtimeName
Feeds used:
https://www.myget.org/F/aspnetcidev/

Also, I have tried to restore the package to net451, dnx451, dnx46 - without result.

[Kukkimonsuta]

@tstar You need to add "Microsoft.NETCore.Platforms": "1.0.1-rc2-*" to your dependencies - or at least I think that's how I got it working.

Also to the team - thanks for releasing this for the few that try to keep up with you on rc2 branch, much appreciated! :+1:

[tstar]

Everything worked out! Thank you!

[Eilon]

Regarding an earlier question, at this time there's no plan to publish DNX for RC2. Everything should be dotnet-cli.

[cwe1ss]

I'm using your DI system together with Castle Windsor and I had some issues with this. Since AddMvcDnx adds additional IAssemblyProvider and ICompilationService implementations, the container now contains 2 implementations. It seems like it always resolved the first one and therefore, the app didn't work.

I had to manually remove the default implementations before calling AddMvcDnx:

services.Remove(services.First(x => x.ServiceType == typeof(IAssemblyProvider)));
services.Remove(services.First(x => x.ServiceType == typeof(ICompilationService)));
services.AddMvcDnx();

Do you think that not removing the original implementations is an issue of AddMvcDnx or should the DI adapter resolve this properly? What would be the rule to be consistent with your DI system? Last one wins?

(I'm using an unoffical adapter for Castle Windsor https://github.com/castleproject/Windsor/issues/120 so something could be wrong there either)

[davidfowl]

I'm using your DI system together with Castle Windsor and I had some issues with this. Since AddMvcDnx adds additional IAssemblyProvider and ICompilationService implementations, the container now contains 2 implementations. It seems like it always resolved the first one and therefore, the app didn't work.

This is something we need to resolve here https://github.com/aspnet/DependencyInjection/issues/379. There are a few implicit behaviors that are not captured in our spec that we do rely on. It's possible we should be replacing it in the container but that will come out of investigating how other containers behave and how we expect to consume it.

BTW it would be great if that code for the windsor adapter was on a repository instead of just a gist.

[davidfowl]

It should also use the specification tests https://github.com/aspnet/DependencyInjection/blob/dev/src/Microsoft.Extensions.DependencyInjection.Specification.Tests/project.json#L3

[cwe1ss]

Thank you David!

BTW it would be great if that code for the windsor adapter was on a repository instead of just a gist.

yep... it's on my todo list. Although it seems like the Castle team isn't active anymore...

[pranavkm]

@davidfowl there's a test that covers the behavior we're relying on here - https://github.com/aspnet/DependencyInjection/blob/dev/src/Microsoft.Extensions.DependencyInjection.Specification.Tests/DependencyInjectionSpecificationTests.cs#L254.

[cwe1ss]

I was able to fix my Castle adapter and created a repository for it. (I'll release it to nuget later) Thank you for pointing out the specification tests - they are really helpful!

[Eilon]

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.