'ViewContext' does not contain a definition for 'Controller'

[Halofreak1990]

For purposes of learning the new MVC 6 framework, I am in the process of converting a basic MVC 5 project to MVC 6. However, this project uses a few custom HtmlHelper extension methods, some of which use the Controller property of the htmlHelper's ViewContext to retrieve an UrlHelper instance to build an URL based on the passed 'action' and 'controller' parameters. This, however, produces the titular error message.

Was the omission of the Controller property an oversight or intentional, and if intentional, what do you suggest as workaround?

[pranavkm]

cc @rynowak

[rynowak]

@dougbu @Eilon - should we expose IUrlHelper on IHtmlHelper? We do this with a bunch of other stuff https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.ViewFeatures/Rendering/IHtmlHelper.cs

[Eilon]

@rynowak it does seem like a common need. I just wish there was a pattern for extension methods (e.g. on IHtmlHelper to get stuff from DI... I suppose an extension method can manually resolve the service, but that's not very pretty.

[rynowak]

Regardless, IUrlHelper seems like the one missing piece here.

I'd say if you need more services than HtmlHelper uses you should extend and @inject, but we should have a low bar to write extension methods that do similar things to default HtmlHelper.

[dougbu]

Agree end users don't need IUrlHelper hanging off IHtmlHelper. Already have a Url property injected in all IRazorPages.

But those writing IHtmlHelper extension methods are less likely to need an IUrlHelper than the IHtmlGenerator, which is the only place our helpers use an IUrlHelper.

What's most surprising to me is that IHtmlHelper exposes JavaScriptEncoder and UrlEncoder but not HtmlEncoder.

[Eilon]

@rynowak you can't @inject if you want more than one component to replace the Html property. But then, that was always a problem even before @inject, so yeah just use @inject to add whatever made-up helpers...

@dougbu why would HTML helpers be any less likely to need URL helpers? That's probably the most common case. No one replaces IHtmlGenerator.

[dougbu]

No one replaces IHtmlGenerator.

Agreed. But those extending IHtmlHelper have to get it from DI. That is, it's not exposed on IHtmlHelper.

Separately I dislike exposing IUrlHelper in IHtmlHelper because our IHtmlHelper implementation itself has no need of it. Exposing the IHtmlGenerator on IHtmlHelper and, perhaps, exposing IUrlHelper on IHtmlGenerator have no similar issues.

[Eilon]

Not sure I understand. Are you saying someone writing an HTML helper needs IHtmlGenerator? I doubt that almost any helper would go through that effort...

[dougbu]

Are you saying someone writing an HTML helper needs IHtmlGenerator? I doubt that almost any helper would go through that effort...

Using tried-and-true "if we need it, so will they" logic, those extending IHtmlHelper will definitely need the IHtmlGenerator. And, conversely, those extending IHtmlHelper probably won't need the IUrlHelper. If that logic doesn't hold water here, I got nothin.

[Halofreak1990]

@dougbu I don't immediately see the problem with, for example, exposing Controller, which has an IUrlHelper property, via the ViewContext, like it was before.

[Eilon]

@dougbu I doubt anyone would write helpers like ours, because ours are just core fundamental input elements. Most helpers I've seen are more domain-specific, and don't re-use our stuff, or people just write their own stuff from scratch.

[emoangelov]

Is there any further development on the issue with accessing the controller?

[dougbu]

@Halofreak1990 we mostly discussed IHtmlHelper extension methods in general. Were we correct you're less interested in the Controller instance than the IUrlHelper it exposes?

If yes, I recommend creating a brand new helper class over extending IHtmlHelper. That new class could be brought into a view using @inject. To get an IUrlHelper, include an IUrlHelperFactory parameter in its constructor and have the class implement IViewContextAware. Its Contextualize() method could invoke the factory to get the IUrlHelper you need. (Or, it could save the ViewContext for lazy-loading the helper later.)

[Halofreak1990]

Were we correct you're less interested in the Controller instance than the IUrlHelper it exposes?

Yes. That's correct.

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.