Feature Request/Question: Ability to easily author/inject new directives for Razor?

[mkArtakMSFT]

From @Fir3pho3nixx on March 24, 2018 18:58

Currently, I cannot find an easy way to author/inject custom directives into Razor whilst using ASPNET Core Mvc(Kestrel).

I can see that the @Inject directive gets registered within razor here. Now if I wanted to inject a custom directive to MVC on startup how would I achieve that easily? Imagining for a second I wanted to create a '@FooInjector'.

I can see you offer access to RazorViewEngineOptions is this potentially where you guys would expose something like this?

Copied from original issue: aspnet/Mvc#7540

[mkArtakMSFT]

From @rynowak on March 25, 2018 23:47

We plan on enabling this kind of thing once we have support for it in tooling.

While it would be possible for us to provide support for this in the runtime/compiler right now, the tools would not understand the new directives and would produce errors.

[mkArtakMSFT]

@rynowak, do we have a separate issue tracking this work, or should we use this one for tracking?

[mkArtakMSFT]

From @rynowak on March 26, 2018 18:7

We don't have an issue for it, but its on our roadmap and planning documents.

If you're deeply passionate about having an issue for it, then Razor repo is the right place to track.

Guys sorry this ended up here. All I was asking for was a way to inject directives for a razor view engine via kestrel. Somehow this got turned into a tooling cluster fuck. Not what I meant.

[rynowak]

That's the answer though.

This is not easily possible today, we plan to make it work in the future, but only when it will work end to end.

Ok first of all, I totally respect your team and thanks for designing this product so well that I could inject new directives. Seriously job well done team. Your design is spot on keep it going ...

** Warning crazy long ass rant with expletives about the fucking mentalists in the aspnet team. **

Why am I asking for this so soon?

Background

I have joined the castle project as an OSS contributor. We might all think they are "passed due" but unfortunately the fact is they invented the first IoC container for dotnet. They also had some really gifted developers which evolved their envisioning of what module inversion would look like today(sic: https://en.wikipedia.org/wiki/Inversion_of_control). IoC containers now are a dime a dozen. Windsor was first period, they learnt all of these problems a long time ago.

Crazy drugged up, drunken mother f%#king David Fowler invented Microsoft.Extensions.DependencyInjection.Abstractions. This made some really bold assumptions about how containers work today. It completely ignored the framework offering of the disposable pattern and augmented scoped behaviour with a god damn service locator pattern. F%#king rubbish really considering it earned us(Castle) the title of non-conforming container.

If you think service location is bad please ask Ploeh.

The point

The only reason I am asking for this feature via kestrel is because I believe I need to write a new @Inject directive based on this experimental PR which led to this failed PR. Your work here is only expedited by the failings of aspnet/Mvc#5403.

Conclusion

Please take your time on this one. You guys are doing a great job, I am unfortunately trying to work round what the aspnet d1ckh3ds gave us to work with. No rush.

Again this is not what I meant.

@davidfowl

#IWillNotLetThisGoUntilYouFixIt

[generik0]

As I understand, however correct me if I am wrong, but Autofac had to rewrite there own service collector to get this to work, and simpleinjector use cross wiring of sorts to get thins to work. I have also seen a Ninject example that cross wires.
I have seen posts where many other major IoCs just give up wiring into aspnetcore.

Hence, I believe “Huston, We have a problem”.

@generik0

I have seen posts where many other major IoCs just give up wiring into aspnetcore.

Can you please post examples of this? I know of one place where you can see how many IoC containers are cut out by this please see link below:

https://github.com/danielpalme/IocPerformance/blob/master/README.md

F%#king shocking. This is disgusting and devalues my opinion of Microsoft today.

Hence, I believe “Huston, We have a problem”.

IoC library developers all over the place I crawling up their own ass to make this work. I wish people at Microsoft could see the pain they caused.

@microsoft

You lot are villain, not community driven. A complete violation of OSS.

castleproject/Windsor#120 (comment)

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[NTaylorMullen]

@allisonchou compiler ❤️