Like many other developers I have been excited to see that WCF RIA Services has gone beta and now comes with a Go-Live license. After this release my team at Wash U began developing a few applications using the new RIA Services bits. We have been very impressed with the productivity increase as well as several other features that RIA provides over the previous straight up WCF services have offered in the past.
All was going well, until it came time to publish the first application to the staging (user testing) server. Upon deployment the application started displaying the “Initializing Application” progress control for close to a minute.
After which the application would throw an error: “Load operation failed for query ‘GetUser’. Unable to connect to SQL Server Database.“
This was a very strange error since we had configured the application to use Windows authentication and where not connecting to the application’s database on the initial screen. While the application was running on our local development machines everything worked fine, the application fired up and displayed the currently logged in username in the upper right of the application. So we looked at the configuration again to see if there was anything that we missed. By default RIA is configured to use Forms authentication. (As a side note, I found this post by Brad Abrams concerning the decision on which authentication method was more common: Forms Auth\Windows Auth – what is more common? ) Given this, the default configuration looks like this (Please note this is trimmed to display only the configuration elements used by the Authentication Service):
<roleManager enabled="true"/>
<authentication mode="Forms">
<forms name=".RiaWinAuthExample_ASPXAUTH" />
</authentication>
<profile>
<properties>
<add name="FriendlyName"/>
</properties>
</profile>
To get RIA to use Windows authentication on the local developer workstations we simply had to change the authentication element to the following:
<authentication mode="Windows" />
After verifying that the configuration published to the server did in fact contain this change we went on a hunt to find out why this would not work outside of localhost. One of the first articles we found was Tim Heuer’s post Deploying your Silverlight and WCF RIA Services application. This post shed a lot of light on possible details that may have been overlooked. After double checking the items mentioned in Tim’s article we continued to have the issue. (BTW: You may also need to add the System.ComponentModel.DataAnnotations.dll assembly to the list of items to set to “Copy Local” in addition to the items listed in the bin or not to bin section of the article.)
After digging some more and not finding much help on <Insert your favorite search engine here>, I decided to do some ground up debugging. This lead to several hours of starting new RIA projects, changing something, deploying it to a server and zeroing in on the problem. Eventually I came up with the following list of issues that were causing the error.
- The System.ComponentModel.DataAnnotations.dll was not included in the bin folder on the server.
- This was fixed by setting the Copy Local property of the reference to true.
- We had neglected to enable impersonation in the configuration for the site. This was simply a silly mistake as we do this for all of our internal web applications.
- Love it or hate it, we are pretty much required to use impersonation due to auditing requirements we have because of HIPAA regulations. I realize that there are other ways; however, this is the most straightforward way for us to be in compliance today. Going forward we are looking into possibly implementing other solutions.
- There are some additional configuration changes that are required when deploying to a non-developer workstation.
- Specify the defaultProvider for the roleManager as: AspNetWindowsTokenRoleProvider
- Set the enabled attribute on the profile element to false!
- If you are using profiles the instead of setting this to false, the provider needs to be configured to use the proper database. If you need more information about profile providers, this article should get you started: ASP.NET Profile Providers
I realize that some of this may be the result of trying to rush the application out for demo; however, with the exception of Tim’s article there was not much on the web about deployment. Information about deploying using windows authentication is even more scarce. My hope is that this article will document all of the information in one place to save others the trouble of piecing this together for the many source I had to use.
Summary \ Solution
- Check out Tim’s article to cover the RIA deployment bases.
- Make sure IIS is properly configured to use Windows authentication. This is the same configuration for any other ASP.Net application that uses Windows authentication, nothing special here.
- Ensure that System.ComponentModel.DataAnnotations.dll and all other referenced RIA assemblies are deployed to the bin folder on the server or RIA is installed on the server.
- If you need impersonation, make sure it is specified in the configuration! (man, this one make me feel sloppy in my case)
- Set the corresponding configuration elements as follows:
- Again, this is trimmed to only show the sections the authentication service is concerned with, and the impersonation configuration is included. You may or may not need the identity element for your application. Like IIS impersonation settings are the same as any ASP.Net site, so follow the same rules regarding it.
<identity impersonate="true"/>
<authentication mode="Windows" />
<roleManager enabled="true"
defaultProvider="AspNetWindowsTokenRoleProvider"/>
<profile enabled="false" />
To summarize, the issues we encountered were related to:
- ASP.Net’s default configuration attempting to use a local SQL Express database for membership, roles and providers. This was solved by using the proper configuration. For us, that meant disabling profiles altogether and changing the default role provider.
- RIA assemblies are not deployed with the site by default and needed to be configured to be copied to the bin folder of the site or the RIA bits needed to be installed on the server.
- Impersonation needed to be set to allow access to server side resources. (database connections, file system resources etc.)
- I cannot stress enough that this may not apply to your application and needs to be considered based on your environment before enabling it. There are security philosophies that say this is an “evil” configuration.
I sure hope this saves other RIA developers some time and hair loss. Due to the voodoo that is RIA services, this was not necessarily an easy issue to figure out. I had to use Fiddler, Reflector and read several articles before it finally became clear. Once all of the pieces were exposed to the light it all made since, but brining it out of the “black magic” proved to be more challenging that it “should” have been. I guess that is the trade off for having such an easy development “story.”
Either way, I must say I am really digging the power of RIA and I have to recommend it to anyone want to build stunning LOB applications. So if you haven’t already, dig in and be amazed.
Happy Coding… err… Designing … umm … RIA Using.
As always, feedback is encouraged and appreciated!