I first saw the Patterns & Practices Upcoming Release Roadmap a while back, but after starting new development on my app written in Silverlight 4, I had another glance at the roadmap, http://msdn.microsoft.com/en-us/practices/bb232643#3, which has great news about support for Silverlight 5.0. Prism 4.0 has been updated to 4.1, but it looks as if Windows 8 metro apps are supported with the next release (5.0?) http://msdn.microsoft.com/en-us/practices/bb232643#1? MVVM is a truly great pattern and with Prism you more or less have it all…
I’m currently redesigning an application to be Silverlight-based and implemented by using Prism. I’ve opted to use RIA Services to connect to the Entity Framework model, hosted by an ASP.NET Web application. However, to modularize it with Prism, I needed to remove the coupling between the ASP.NET Web app (Silverlight host) and the consumer, my Silverlight app, and I used Colin Blair’s idea, http://www.riaservicesblog.net/Blog/post/RIA-Services-Enterprise-Business-Application-Attempt-Part-One.aspx, as inspiration, not to mention copy much of the example code. 😉
Now, what I’m not so sure about, is whether to have the application services, including authentication (ASP.NET authentication), as a separate Prism module, or to have it as a shared assembly, tightly coupled/referenced from the Silverlight application.
Currently I am creating a Prism module for the horizontal application services, beginning with the authentication service, even if that takes a little more development. What do you think, should I opt for the shared assembly instead?
I started getting this error message, after installing SP1 for Visual Studio 2010.
The “CreateRiaClientFilesTask” task failed unexpectedly.
System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain.
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)
It turns out that some sort of locking is the culprit, so simply shut down the ASP.NET Development Server and rebuild your solution.
—————————— UPDATE ———————————–
If the ASP.NET Development Server hasn’t been started yet, or you are using IIS, you need to close down VS 2010, and restart it.