Disambiguate duplicate Microsoft.AspNetCore.DiagnosticsViewPage.Views.* type names

[Eilon]

The types in this namespace come from https://github.com/aspnet/Diagnostics/tree/dev/src/Microsoft.AspNetCore.DiagnosticsViewPage.Sources and are included in two other projects. This means we have the exact same public type names in two different assemblies, which isn't ideal. Nothing actual bad happens, but it's a bad practice.

We should look into one of these:

1. If possible, make the type internal. Case closed.
2. If they must be public, put the types in different namespaces based on where the types are included. E.g. use an #ifdef in the .Sources package to do something like #if EF 'namespace foo.EF' #elseif ASPNET 'namespace foo.AspNet' #else #error #endif

Update1 (kichalla):
New path: https://github.com/aspnet/Diagnostics/tree/dev/src/shared

[Eilon]

For completeness, the three types in question are:

1. Microsoft.AspNetCore.DiagnosticsViewPage.Views.AttributeValue
2. Microsoft.AspNetCore.DiagnosticsViewPage.Views.BaseView
3. Microsoft.AspNetCore.DiagnosticsViewPage.Views.HelperResult

[Eilon]

@danroth27 FYI not planning on doing this for 1.0.0... how critical is this for the docs?

[danroth27]

Currently docfx will produce a warning when it detects these types with the same namespace and name and it will only document the first one it finds. The warnings are annoying, but I think the output will still be correct given that these types are in fact structurally the same.

[ardalis]

What is the current workaround for this? I'm updating a project from RC1 to RC2 and the last bug I'm trying to resolve is this:

Error CS0433 The type 'AttributeValue' exists in both 'Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'Microsoft.AspNetCore.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' NotFoundMiddlewareSample..NETCoreApp,Version=v1.0 \BaseView.cs 129 IntelliSense Active

Searching for solutions to disambiguate suggest using extern alias or reflection, neither of which is ideal. Is there an RC2/RTM workaround available?

[ardalis]

I ended up being able to avoid using the type. Still curious how a customer who needed it would get around this issue, though.

[Eilon]

@ardalis why do you need this type? No app should ever need these types... They are basically internal implementation details of the various diagnostics pages. I don't even think an app could do anything with these types if it wanted to...

[ardalis]

I have a sample that uses the same pattern as Elm: https://github.com/aspnet/Diagnostics/tree/dev/src/Microsoft.AspNetCore.Diagnostics.Elm including its use of a BaseView class (which I just copied into my sample from the RC1 version). I ended up not needing the type, as you suggest. You can see my code here if you're interested:
https://github.com/ardalis/NotFoundMiddlewareSample/blob/master/src/NotFoundMiddlewareSample/Middleware/BaseView.cs

[Eilon]

Ah, ok, well, you definitely don't want to use the actual types that are in the shipping assemblies. You'll want to just copy the code from the common .Sources package, include that in your project, and the page generator stuff, and then build your "info page" (or whatever).

Now, interestingly, in your case it looks like you're integrating everything into one app? That is, the middleware is part of the app itself? If so, the pattern used in these middleware in this repo probably don't make as much sense: the design of the middleware here just uses pre-compiled and pre-processed Razor to render content. Note, it's actually pre-processed, meaning that there's no Razor used at runtime! This is very different from how a normal MVC page renders. The pattern used in this repo is meant for 100% standalone components. If you're building something into an app, I'm not sure this pattern is all that useful, because once you're in an app, you can make a lot more assumptions about the environment you're in (e.g. you know you're using MVC, etc.).

[ardalis]

For the sample (for an article), it's all in one app, but if one were to try to use it "for real" the middleware would certainly be separated into a reusable package and just added via dependency to other apps. Thanks!

[Eilon]

@kichalla let's discuss this one when you get to it.