Put models folder into a new project named DataAccessSample from SwaggerODataSample solution

[fusionshen]

Hi,

I have a bug in my demo when I use SwaggerODataSample(aspnetcore),and I do not know how to do with the DI of my new project DataAccessSample into startup.cs.

### The log is:
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.AspNet.OData.TypeExtensions.<>c__DisplayClass23_0.b__0(IEdmStructuredType t) in C:\Users\Fusionshen\Downloads\aspnet-api-versioning\src\Common.OData.ApiExplorer\AspNet.OData\TypeExtensions.cs:line 137
at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable1 source, Func2 predicate, Boolean& found)
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable1 source, Func2 predicate)
at Microsoft.AspNet.OData.TypeExtensions.GetStructuredType(Type type, IEdmModel model, IEnumerable1 assemblies) in C:\Users\Fusionshen\Downloads\aspnet-api-versioning\src\Common.OData.ApiExplorer\AspNet.OData\TypeExtensions.cs:line 137 at Microsoft.AspNet.OData.TypeExtensions.SubstituteIfNecessary(Type type, IServiceProvider serviceProvider, IEnumerable1 assemblies, ModelTypeBuilder modelTypeBuilder) in C:\Users\Fusionshen\Downloads\aspnet-api-versioning\src\Common.OData.ApiExplorer\AspNet.OData\TypeExtensions.cs:line 53
at Microsoft.AspNetCore.Mvc.ApiExplorer.ODataApiDescriptionProvider.GetApiResponseTypes(IReadOnlyList1 responseMetadataAttributes, Type responseType, IServiceProvider serviceProvider) in C:\Users\Fusionshen\Downloads\aspnet-api-versioning\src\Microsoft.AspNetCore.OData.Versioning.ApiExplorer\AspNetCore.Mvc.ApiExplorer\ODataApiDescriptionProvider.cs:line 556 at Microsoft.AspNetCore.Mvc.ApiExplorer.ODataApiDescriptionProvider.<NewODataApiDescriptions>d__33.MoveNext() in C:\Users\Fusionshen\Downloads\aspnet-api-versioning\src\Microsoft.AspNetCore.OData.Versioning.ApiExplorer\AspNetCore.Mvc.ApiExplorer\ODataApiDescriptionProvider.cs:line 324 at Microsoft.AspNetCore.Mvc.ApiExplorer.ODataApiDescriptionProvider.OnProvidersExecuted(ApiDescriptionProviderContext context) in C:\Users\Fusionshen\Downloads\aspnet-api-versioning\src\Microsoft.AspNetCore.OData.Versioning.ApiExplorer\AspNetCore.Mvc.ApiExplorer\ODataApiDescriptionProvider.cs:line 172 at Microsoft.AspNetCore.Mvc.ApiExplorer.ApiDescriptionGroupCollectionProvider.GetCollection(ActionDescriptorCollection actionDescriptors) at Microsoft.AspNetCore.Mvc.ApiExplorer.ApiDescriptionGroupCollectionProvider.get_ApiDescriptionGroups() at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GetSwagger(String documentName, String host, String basePath, String[] schemes) at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.<Invoke>d__6.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Hosting.Internal.RequestServicesContainerMiddleware.<Invoke>d__3.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Frame1.d__2.MoveNext()
### The bug location:

It seems that the DI of my new project DataAccessSample is not ok.

what can I do?

Regards

[SiberaIndustries]

I spend alot of time with exactly the same exception when I've tried to migrate a project to the beta release. I ended up with removing all unnessecary Code and figured out that when I just have only one ODataController with a simple Get method it is fine (but swagger doesn't creates a good documentation, see following example) and when I use ProducesResponseType it produces exceptions.

Working:

[ODataRoutePrefix("LibraryItems")]
[ApiVersion("1.0")]
public class LibraryItemsController : ODataController
{
    [Produces("application/json")]
    [ODataRoute]
    public IActionResult Get() => Ok(Repository.All.ToList());
}

Not working:

[ODataRoutePrefix("LibraryItems")]
[ApiVersion("1.0")]
public class LibraryItemsController : ODataController
{
    [Produces("application/json")]
    [ProducesResponseType(typeof(ODataValue<IEnumerable<LibraryItem>>), 200)] // Exception !!
    [ODataRoute]
    public IActionResult Get() => Ok(Repository.All.ToList());
}

Startup:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddApiVersioning(options => options.ReportApiVersions = true);
    services.AddOData().EnableApiVersioning();
    services.AddODataApiExplorer(options =>
    {
        options.GroupNameFormat = "'v'VVV"; // 'v'major[.minor][-status]
        options.SubstituteApiVersionInUrl = true;
    });

    services.AddSwaggerGen(options =>
    {
        var provider = services.BuildServiceProvider().GetRequiredService<IApiVersionDescriptionProvider>();
        foreach (var description in provider.ApiVersionDescriptions)
        {
            options.SwaggerDoc(description.GroupName, new Info { Version = description.ApiVersion.ToString() });
        }

        options.OperationFilter<SwaggerDefaultValues>();
        var xmlComments = Path.Combine(AppContext.BaseDirectory, $"{Assembly.GetEntryAssembly().GetName().Name}.xml");
        if (File.Exists(xmlComments))
        {
            options.IncludeXmlComments(xmlComments);
        }

        options.AddSecurityDefinition(
            "oauth2",
            new OAuth2Scheme
            {
                Type = "oauth2",
                Flow = "implicit",
                Description = "OAuth2.0 implicit flow",
                TokenUrl = configuration.GetValue("jwtIss", configuration["Jwt:Iss"]) + "/connect/token",
                AuthorizationUrl = configuration.GetValue("jwtIss", configuration["Jwt:Iss"]) + "/connect/authorize",
                Scopes = new Dictionary<string, string> { { "api1", "Access scope for " + ShortAssemblyName } }
            });
        options.AddSecurityRequirement(new Dictionary<string, IEnumerable<string>> { { "oauth2", new[] { "api1" } } });
    });
    // Some EF Core dependencies ..
}

public void Configure(IApplicationBuilder app, IApiVersionDescriptionProvider provider, VersionedODataModelBuilder modelBuilder)
{
    app.UseMvc(routeBuilder => routeBuilder.MapVersionedODataRoutes("odata", "api", modelBuilder.GetEdmModels()));
    app.UseSwagger();
    app.UseSwaggerUI(c =>
    {
        foreach (var description in provider.ApiVersionDescriptions)
        {
            c.SwaggerEndpoint($"/swagger/{description.GroupName}/swagger.json", description.GroupName.ToUpperInvariant());
        }
    });
}

I try to keep this Comment short so I can tell you more about missing IModelConfiguration etc. if needed.

[commonsensesoftware]

Sounds like this might be bug. Were either of you migrating from Web API? I can't help, but wonder if the same issue exists there. Much of the implementation source code is shared. If either of you have a simple repro you can share, it really helps me cut down on investigation time.

From what I'm seeing, it appears that the lookup for the specified response CLR type to the EDM type is failing. Behind the scenes, the API explorer will build a surrogate type for Swagger if, and only if, the current CLR type doesn't have 100% parity with the EDM type. This enables you to define a single model, but still yield a filtered CLR type for Swagger based on the EDM. This is particularly useful since most model changes are additive.

Thanks for trying the beta and reporting this.

[SiberaIndustries]

Yes, we are currently working with OData 7.0.1 in an ASP.NET Core 2.1 App which is working as a Web API and it runs very well atm. It looks like the Swagger is taking care of the model configuration of Entity Framework Core too. Because when I've tried to build a new simple Web API project (without EF Core), the EDM-Gen told me to define keys for the entities, furthermore there was no releation between entities.

We are using Owned Types, Shadow Properties, Global Query Filters and some navigation properties have circular references. I guess this can be a reason but our current project is a way too complex to reduce it to a simple example quicky, sorry. But as I said, the entities are mapped correct atm.

Maybe @fusionshen agrees so we can try to look at this point in more detail. I'll keep trying to isolete the reason of this issue.

[fusionshen]

Thanks for your replies. @Discjoggy @commonsensesoftware

I build a repo for the issue. https://github.com/fusionshen/SwaggerODataSample
the swaggerUI may crash, but url is ok.(http://localhost:5000/api/Orders)

[commonsensesoftware]

Apologies for the delay. I finally have a bit of time to circle back around on this.

@Discjoggy does your model contain any nested complex types, entities, or collections? My cursory examination confirms that these scenarios are not currently supported. I took a stab at seeing what it would take and I quickly went cross-eyed. Substituting types out dynamically at sublevels is technically possible, but it's really complicated. Full or partial object-graph substitution would be a great enhancement, but the complexity will take some time. If this is your scenario, my recommendation is to provide your own stand in model for the Swagger model. That should bypass the other checks. Substitution only occurs when the response model doesn't exactly match the corresponding EDM structured type.

@fusionshen thanks for the repro. It looks like you've just shuffled the original demo bits around, so I don't see why it shouldn't work. I'll dig into a bit more and see if I can't track down the issue. It may be the same cause for @Discjoggy issue.

Thanks for your patience.

[spasarto]

I was encountering the same issue, and found this workaround. In your Startup's Configure:

applicationPartManager.ApplicationParts.Add(new AssemblyPart(myAssembly));

This is because ODataApiDescriptionProvider uses the ApplicationPartManager to get the list of assemblies to scan for types.

(https://docs.microsoft.com/en-us/aspnet/core/mvc/advanced/app-parts?view=aspnetcore-2.1)

[commonsensesoftware]

Good point @spasarto. That could be why it's not being automatically detected. If that's truly the issue, there are two ways to deal with it. Option 1 is exactly as @spasarto suggests. Option 2 is that you can add to the model builder before you build the models. Dependency Injection is a convenience and not a requirement for things to work.

Either of the following are valid:

public void Configure( IApplicationBuilder app )
{
  var modelBuilder = new VersionedODataModelBuilder()
  {
      ModelConfigurations =
      {
          new PersonModelConfiguration()
      }
  };
  var models = modelBuilder.GetEdmModels();
  app.UseMvc( routes => routes.MapVersionedODataRoutes( "odata", default, models ) );
}

Figure 1: Imperatively create a model builder without any Dependency Injection

public void Configure( IApplicationBuilder app, VersionedODataModelBuilder modelBuilder )
{
  modelBuilder.ModelConfigurations.Add( new PersonModelConfiguration() );
  var models = modelBuilder.GetEdmModels();
  app.UseMvc( routes => routes.MapVersionedODataRoutes( "odata", default, models ) );
}

Figure 2: Add to a model builder supplied via Dependency Injection

[commonsensesoftware]

I've been able to confirm this is actually a bug that occurs in two parts:

1. When the model type is a different assembly it may not be automatically added to the AssemblyPartManager, which is how assemblies are discovered by default
2. It is [falsely] assumed that a model type should be mapped to a CLR type from the available assemblies. This may not be true when part 1 is true, making the CLR type undiscoverable, and can actually result in a NullReferenceException.

I should have both of these issues fixed shortly and published in the next release.

In the meantime, you can work around the issue as @spasarto suggested or simply change line 27 in your example to:

services.AddMvc().AddApplicationPart(typeof(Order).Assembly);