My OData service needs to support multiple-accounts, which is done by having a route-prefix of {account}.
I can then parse the string in the route to determine which account to run against dynamically (rather than having multiple services set up for each account). For example I have the following URL:
http://server/odata/myaccount/Customers(1)
- which will get customer 1 from account 'myaccount'.
Everything runs perfectly until I come to generate a service document, in this scenario the URI would be
http://server/odata/myaccount/
and the configuration.VirtualPathRoot would be
/odata
The Microsoft.Data.OData.Atom.ODataAtomServiceDocumentSerializer uses the BaseUri from the MessageWriterSettings to set the xml:base attribute on the service node, so it get's set incorrectly to
http://server/odata
In the case where the route prefix is fixed this is still a bug but could be overcome by passing the prefix in with the writer settings, however, in the case where the prefix is dynamic (as here) this is not an option.
Ideally the service document should use the correct path based on the RequestURI and not be hardcoded to the BaseURI which is not correct in all scenarios.
Comments: Thanks for reporting this. I've checked in a fix: http://aspnetwebstack.codeplex.com/SourceControl/changeset/3668c8ff374c
I can then parse the string in the route to determine which account to run against dynamically (rather than having multiple services set up for each account). For example I have the following URL:
http://server/odata/myaccount/Customers(1)
- which will get customer 1 from account 'myaccount'.
Everything runs perfectly until I come to generate a service document, in this scenario the URI would be
http://server/odata/myaccount/
and the configuration.VirtualPathRoot would be
/odata
The Microsoft.Data.OData.Atom.ODataAtomServiceDocumentSerializer uses the BaseUri from the MessageWriterSettings to set the xml:base attribute on the service node, so it get's set incorrectly to
http://server/odata
In the case where the route prefix is fixed this is still a bug but could be overcome by passing the prefix in with the writer settings, however, in the case where the prefix is dynamic (as here) this is not an option.
Ideally the service document should use the correct path based on the RequestURI and not be hardcoded to the BaseURI which is not correct in all scenarios.
Comments: Thanks for reporting this. I've checked in a fix: http://aspnetwebstack.codeplex.com/SourceControl/changeset/3668c8ff374c