Activate attribute's functionality should be split between a FromServicesAttribute and a ContextActivatorAttribute.

[harshgMSFT]

Currently Activate attribute is used to inject services and context objects into controller properties
like so

        [Activate]
        public ActionContext ActionContext { get; set; }

        [Activate]
        public IUrlHelper Url { get; set; }

This is problematic because the types (like ActionContext) being provided aren't actually available as a services.GetService call (or ctor injection).
These should be separate attributes, which can help bind the values from different sources (one from services and the other one for well known type lambda expressions).

[dougbu]

@harshgMSFT what is the specific problem here? the activators are all specific to the type (controller, page, view component) they're activating. so the mix of sources is well understood and it isn't clear why the activated instance should need to know about the distinct sources.
we could have [Activate] cover only types not available in DI (because existing classes with [Activate] properties are created using an ITypeActivator, constructor injection Just Works(tm) for services) but some others seem to like having multiple solutions for providing services.

[harshgMSFT]

Well the problem is - No clear separation of well known types ( which are known to the specific activators) and Services injected from DI. Its to do with Parameter and property injection using model binding. When we do that #801,#38, then there would be a model binder which works on injecting services for properties and parameters. That model binder will get selected based on a binder marker which is something like [FromService] , so for services having both FromService and Activate didn't make much sense to me.
We need to reach a conclusion on which pattern to support here. Obviously we still need to have Activate since classes like viewComponent are not populated using model binding, but we should avoid having two attributes which do similar things.

[yishaigalatzer]

I don't see strong argument above, closing as won't fix.