Wednesday, October 19, 2011

Markup Extensions in Silverlight have to be public

In the good-to-know category we today have a problem out of the Silverlight 5 world, where Markup Extensions are now possible. Beware though: If the class is not public Silverlight will simply freeze while starting without giving a proper error message. So always be sure to make your extensions public.

Good to know and would have saved me quite some time if I knew that beforehand.

Submit this story to DotNetKicks

Monday, August 8, 2011

Authentication Suffix in SharePoint hosted Data Service

When hosting a Data Service inside SharePoint using the MultipleBaseAddressDataServiceHostFactory you might notice that your service endpoints get redirected depending on the authentication schema (as described here). The way it is supposed to work is that you do not notice any of the redirections on the user side.
But the way the default behaviour works is that also the service base will change accordingly. I.e. if you load the .svc for anonymous authentication the base attribute on the service will look like this:

xml:base="http://localhost/_vti_bin/test/odataservice.svc/anonymous/" xmlns:atom="" xmlns:app="" xmlns="">

(Notice the anonymous part in the base attribute.)

But any request to the service with the authentication suffix be it anonymous, basic etc... will be interpreted by your OData framework and thus you get the error message: Resource not found for segment 'basic' when navigating to http://localhost/_vti_bin/test/odataservice.svc/basic/Customers for example. This is because internally the url is .../basic/basic/Customer after the redirect according to the authentication schema.

Since some services actually rely on the correct base-url (e.g. PowerPivot) that is not the behaviour we would want to see.

The not so well documented fix for that behaviour is to set the ServiceFactoryUsingAuthSchemeInEndpointAddressAttribute on your service class like this:

[ServiceFactoryUsingAuthSchemeInEndpointAddress(UsingAuthSchemeInEndpointAddress = false)]

Afterwards you will have the much more sensible behaviour of a clean base-url in your .svc service description and no more confused clients which access your service through the authentication suffixes.

Submit this story to DotNetKicks