Generating CSV containing custom Metadata

I need to create a CSV file containing some specific information about all my services defined in a server. It should contain the following information:

RequestDTO class;API Route;HTTP Verb;Required Roles;Required Permissions;

All of this information can be found in the METADATA and a lot more. The question is if there is anything I could use from inside ServiceStack which allows for easy extraction of what I need in the CSV File. I ask before I start with the .NET Reflection KungFu, especially because the information can be in different places such as the definition of the DTO and the service implementation classes … :worried:

Thanks.

Hi @tbednarz,

You don’t have to do your own reflection to get this info, you can use HostContext.Metadata.OperationsMap to see all the data you need, but since it is in a nested format, you’ll likely want to extract and restructure to be more CSV friendly.

The same data is available from /types/metadata path on ServiceStack hosts as well. Eg,

https://web.web-templates.io/types/metadata

Hope that helps :+1:

Hi @layoric,
Thanks a lot for that hint, I was not aware of this class.

I was digging a bit into it and found, that the Routes property of the Operation object is not filled, it has always 0 entries. This is my code:

 var operations = HostContext.Metadata.Operations;
Logger.Debug($"Found {operations.Count()} Request Operations.");
foreach (var operation in operations)
{
	Logger.Debug($"Operation name: {operation.Name} | Type: {operation.RequestType} | RestRoute: {operation.Routes.Count}");
	if (operation.Routes.Count > 0)
		Logger.Debug($"RestRoute has {operation.Routes.Count} elements.");

}

It found more than 250 endpoints but none has a RestRoute. I can do

var custAttrs = operation.RequestType.GetCustomAttributesData();

and then walk through those attributes and their constructor attributes etc all down the object tree. I can find it there deep in the tree.
Is there a reason why Routes is not populated or am I looking at the wrong spot?

Are you inspecting the API after the AppHost has initialized, e.g. within a Service impl?

Hi @mythz,
Nope for testing and easy debugging I called my implementation very early in the service bootstrapping process in AppHost.Configure() just after I setup my logger.

Since you are asking I guess that is too early in the startup process. Is it possible to add it to the AfterInitCallbacks or do I have to create an endpoint for it (implement a service for this functionality)?

Yeah AfterInitCallbacks is fine, for a no-touch approach you could also add a Modular Startup class implementing IAfterInitAppHost

Hi @mythz,
Thanks Demis, works fine in AfterInitCallbacks and is populated with what I need. Still learning new stuff even after almost five years of using ServiceStack. :wink:

1 Like