Startup.cs in another assembly causes OData to return 404.

[joshmackey]

Still tracing down exactly what's happening, but I have a simple ASP.Net Core Startup class that configures OData with api versioning.

If I run the Startup class in the entry dotnet core assembly, everything works as it should, however, if the Startup class is in a separate assembly, all odata related routes start returning 404 (including the $metadata endpoint).

Trace logging shows that the route is being matched, but no matching actions are found.

Will update as I come across more information.

[joshmackey]

I don't know if it's related or not, but the OData endpoints start returning 404 the moment I call AddApiVersioning(). Seems like the replaced IActionSelector can't find them anymore?

[joshmackey]

It's the following code:

var applicationPartManager = app.ApplicationServices.GetRequiredService<ApplicationPartManager>();
applicationPartManager.ApplicationParts.Add(new AssemblyPart(typeof(VersionedMetadataController).Assembly));

For unknown reasons, it's adding the wrong assembly to the ApplicationPartManager. If I run that code in my Startup class directly, the correct assembly gets added.

[commonsensesoftware]

ASP.NET Core usually needs some help in this type of scenario. This would especially be true if all of the OData configuration is external too. It sounds as though that might be the case since you mentioned that you need to add the VersionedMetadataController.

Were you able to get things working? It sounds like you did. Let me know if there's anything else required to resolve this issue.

Thanks.

[joshmackey]

I worked around it, but it's still an issue to be fixed. typeof(VersionedMetadataController).Assembly should have fetched the correct assembly, but it didn't.

[commonsensesoftware]

This is pretty easy to workaround, but I'm tracking this for a future release. In the next patch, I believe this can be fixed. Thanks.