The types registered for MvcOptions and MvcViewOptions conflicts with other libraries.

[jasselin]

AddMiniProfiler registers a type for MvcOptions and MvcViewOptions that can override or be overidden by another library.

Depending on what library is called first, the last registered type is used by MVC.

For example, FluentValidation does the same and conflicts with MiniProfiler, preventing ProfilingViewEngine from being used.
https://github.com/JeremySkinner/FluentValidation/blob/237ccfd581dcecf72209acdaabd4c41122fad98d/src/FluentValidation.AspNetCore/FluentValidationMvcExtensions.cs#L63

A workaround could be to register the ViewEngine using IServiceCollection.Configure()

services.Configure<MvcViewOptions>(options =>
{
    for (var i = 0; i < options.ViewEngines.Count; i++)
    {
        options.ViewEngines[i] = new ProfilingViewEngine(options.ViewEngines[i]);
    }
});

The same thing applies to MvcOptions which adds ProfilerActionFilter to the Filters collection. Here is my current workaround.

services.AddMvc(cfg =>
{
    cfg.Filters.Add(new ProfilingActionFilter());
})

[NickCraver]

@DamianEdwards Do you have any input here? This seems like it'd be a conflict with every library doing it...what's the best way to share and play nice?

[NickCraver]

I'll try switching Mvc to DiagnosticListener, totally avoiding the issue here. Leaving this as a place to track. Will tackle it as soon as time allows., but definitely before we get to beta, etc.

[jasselin]

@NickCraver Since those classes are now internal, is there a alternative workaround beside copying the classes to my project?

[NickCraver]

So unfortunately I ran into aspnet/Mvc#6222 which is a pretty hard blocker on moving strictly to DiagnosticSource. Hopefully the MVC team can provide some insight soon here.

[NickCraver]

@jasselin since I can't do the move at the moment, I've exposed the bits as public but in the .Internal namespace in 2ea2c3d so you can workaorund in the next build (on MyGet shortly).

[NickCraver]

I talked with the Diagnostic guys at Microsoft and hopefully we'll see some improvement here (concrete types in ASP.NET diagnostic events, since they removed the adapter from 2.x as well). If that happens, it should remove the blocker from using those events and removing the wrapping.

[NickCraver]

I checked again today, unfortunately this still hasn't happened. You can see the anonymous types here: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.ViewFeatures/Internal/MvcViewFeaturesDiagnosticSourceExtensions.cs#L88-L99 and note that DiagnosticAdapter is still only netstandard2.0+ here: https://www.nuget.org/packages/Microsoft.Extensions.DiagnosticAdapter/2.0.0

I'll tale a peek at forking this behavior for netstandard2.0+, but that's non-trivial and just kinda sucks :(

[NickCraver]

Since concrete types are now in - this is unblocked! I'm working on it over in #475.