Skip to main content
Home Forums Silverlight Programming WCF RIA Services .NET RIA Services V1 CTPs: current thinking
82 replies. Latest Post by ringi on October 17, 2009.
(0)
Dinesh K...
Member
52 points
33 Posts
06-09-2009 1:27 AM |
A while back I had mentioned that once we are further along in our planning, we will get back to you for feedback. Since then we have collected significant amount of input from forum discussions and email / in-person conversations. Based on that, here is our current thinking about .NET RIA Services V1. While I have no crystal ball to predict future, my past experience is that plans do change based on feedback, actual vs projected schedule for features and schedules of related projects J
A note on Platforms and tools
Please give us feedback
Here are the kinds of things we would love to have your feedback on to make smarter tradeoffs and prioritization. Again from past experience, we usually have to pick a few priorities to focus on and defer/limit work on others.
MarkMonster
Contributor
5220 points
1,046 Posts
06-09-2009 4:08 AM |
Thanks for this information. We now have at least a timeframe of when to expect this to be ready for us to got into production with RIA Services.
I must admit that I expected this to be available earlier, but I can understand this timeframe. RIA Services is still in the preview stage. So a lot of work to be done still.
Also very interesting to read is the underlying protocol to be changed to ADO.NET Data Services. I think of this as a good thing!
Thanks.
stefancr...
53 points
38 Posts
06-09-2009 5:04 AM |
Thanks Dinesh to publish this roadmap. I'm already looking forward to exploring the July CTP. The things I would like to see improved as soon as possible are:
Features I would like to see in future versions:
ColinBlair
6579 points
1,291 Posts
06-09-2009 7:56 AM |
Excellent, I really like this roadmap. I was a little worried when we heard that the go-live restriction was being dropped next month that RIA Services was going to be rushed out faster then it should be. What exactly is meant by hierarchy support? Does that mean better suppot for inheritance?
I think that .NET 3.5 SP1 will be essential until the .NET 4.0 SP1 timeframe whenever that is. So far, getting IT departments to upgrade Silverlight is pretty easy but upgrading to the first new version of .NET since 2005 is going to take awhile.
zmorris
10 points
6 Posts
06-09-2009 10:09 AM |
Our $0.02:
Running on.NET 3.5 sp1 is a must IMHO. Anyone running on a hosted platform will need this.
Support for VS 2008 SP1 is also a must for us. We see no compelling reason to jump to VS 2010 or .NET 4.0 in the near future.
Integration with Astoria would be great. To bad EF is so horrible.
We don't care about integration with ASP.NET MVC, etc...
Thanks for the update.
jbloomer
42 points
61 Posts
06-09-2009 10:16 AM |
The release date of next year is later than I was hoping, although having a go-live license is good news.
On your questions.
(1) + (2) I'm pretty happy with what RIA enables now, basically a much easier intuitive version of using ADO.Net Data Services to enable data access in my Silverlight applications.
(3) Support for .NET 3.5 SP1 is a must. I can foresee issues getting companies to upgrade to 4 as usually some company wide policy has to be met. VS 2008 SP1 would be nice too, although it's easier to move developers to VS2010 than companies to .NET 4.
(4) Not bothered about using RIA outside of Silverlight.
(5) Not bothered about alignment to ADO.NET Data Services.
BenHayat
Participant
1033 points
601 Posts
06-09-2009 10:42 AM |
zmorris:Our $0.02: Running on.NET 3.5 sp1 is a must IMHO. Anyone running on a hosted platform will need this.Support for VS 2008 SP1 is also a must for us. We see no compelling reason to jump to VS 2010 or .NET 4.0 in the near future. Integration with Astoria would be great. To bad EF is so horrible. We don't care about integration with ASP.NET MVC, etc... Thanks for the update.
06-09-2009 11:43 AM |
BenHayat: If I read correctly between the lines on what Dinesh is saying about moving to VS2010, is "Probably" they need certain features in VS10 for RIA that simply doesn't exist in VS2008 and those features are rooted back to .Net 4.0. So, support for .Net 3.5 and VS2008 would mean two things: a)either sacrifice/discarding introduction of important features that can be had by VS2010 or b)try for the RIA team to reinvent lots of stuff for VS2008 just to support for legacy product and loose/waste valuable resources on VS2008. I think we need to be more cautious for pressing support on VS2008/.Net 3.5, which may take a chunk away from future RIA.
If 4.0 was just another revision release like all of the 3.x series I would agree, but 4.0 is a brand new version and I think IT departments are going to be glacially slow at getting it installed on servers. Putting a 4.0 restriction on RIA Services would be like putting Silverlight's feet in a bucket of cement and throwing it off the dock.
06-09-2009 12:15 PM |
ColinBlair:If 4.0 was just another revision release like all of the 3.x series I would agree, but 4.0 is a brand new version and I think IT departments are going to be glacially slow at getting it installed on servers. Putting a 4.0 restriction on RIA Services would be like putting Silverlight's feet in a bucket of cement and throwing it off the dock.
shan_mca...
21 points
41 Posts
06-09-2009 12:31 PM |
#4 - using Domain Service in ASP.NET, AJAX, and other dynamic data applications - this feature should be considered critical. I would recommend that RIA be designed with AJAX and Silverlight side-by-side to ensure that we don't get into a pattern that we cannot get out of. ie: the current design of RIA requires compiling code and does not expose the metadata through the service - this will make using AJAX and other frameworks very difficult. Please reconsider adding AJAX and ASP.NET to the list of technologies to support as soon as you can in the roadmap. Knowing that you are just putting the final touches on the July CTP, the next ship date after that should be considered for AJAX and ASP.NET, and it should come no later than PDC to ensure that it has a good reception from developers at the conference.
Thanks,Shan
mrdave
74 points
39 Posts
06-09-2009 1:22 PM |
I think to really be able to really weigh the 3.5SP1 vs 4.0 there has to be more details about what would be given up. I know in feedback I have heard from people after giving talks on .NET RIA Services is high interest in having 3.5SP1 support and not requiring .NET 4
micke_
2 points
4 Posts
06-09-2009 2:17 PM |
Does hierarchy support mean that RIA Services will support inheritance? Or does it refer to “the flattening support” mentioned in other posts? To me there is no point starting to develop anything other than test projects with RIA Services until support for inheritance is added, otherwise I would have to redesign my data layer when/if it gets added. At the company I work for I recently evaluated RIA Services to see if it could be used in a quite large project we are undertaking this fall, everyone including me was very impressed by the capabilities of the framework, management was and still is concerned that the technology is very new of course, but looking at all the benefits it was actually looking promising, and we would dig deeper into this. When we used an existing DAL we got stuck on some child classes, reading on this forum we finally learned that there is no planed support for inheritance and RIA was unfortunately not even an option anymore.
Really hope support for inheritance will be added.
06-09-2009 3:18 PM |
The sense I was getting wasn't that it was a 3.5SP1 OR 4.0 question, I think the possibility is 3.5SP1 AND 4.0. The tradeoff isn't what would we lose by not going to 4.0, the tradeoff is what other features would not be worked on since they would have to maintain two different versions of RIA Services.
Going through the feature and scenario list, here are my priorities going forward:
moemeka
147 points
69 Posts
06-09-2009 9:05 PM |
RIA services is awesome. I would love to get a command line utility as part of the CTP build. I dont quite understand why a technology like this is tightly coupled to an IDE. What's the gold star value proposition? If this thing were in the command line I could generate my files and import them into whatever IDE I so desire (a la everything else). Thanks!
MichaelD...
43 points
107 Posts
06-09-2009 11:36 PM |
I can't believe that we're even having a discussion on 3.5 vs. 4.0. RIA is so freaking cutting edge that it would be a disservice to even consider 3.5! Not sure if you've noticed or not, but RIA Services are the only thing holding up the boat to a full VS2010 install currently. :)
06-10-2009 12:40 AM |
MichaelDBang: I can't believe that we're even having a discussion on 3.5 vs. 4.0. RIA is so freaking cutting edge that it would be a disservice to even consider 3.5! Not sure if you've noticed or not, but RIA Services are the only thing holding up the boat to a full VS2010 install currently. :)
Tim Heuer has stated several times that the problem is with VS2010 and not with RIA Services. We are waiting for VS2010 to be upgraded, not RIA Services.
06-10-2009 1:01 AM |
@Colin,
Thanks for the feedback Colin (and Mark and Stefan before your post as well). Sorry, I should have been clearer - especially given our previous threads. By hierarchy, I was referring to compositional hierarchy such as Order-OrderDetails or Payment-PaymentLine etc. We have heard from multiple sources, that this could be simplified further.
You have a good point about 3.5 SP1. We would like to support it if we can - it is more a matter of doing the cost-benefit tradeoff and finding the right packaging and tooling option to manage that. Also, FWIW, there are .NET 4 features we may need to utilize. For example, we are unlikely to be able to support use of .NET RIA Services in medium trust with 3.5SP1.
06-10-2009 1:07 AM |
@zmorris
Thanks for the feedback. A couple of followup questons/comments:
I get some of the issues with hosted platform migration. But what is the blocker for VS 2010? The reason I am asking is that we are working on better tooling capabilities that requier VS 2010 features (in addition to substantial cost of supporting multiple platforms when the benefit is relatively short-lived).
06-10-2009 1:13 AM |
@jbloomer
Thanks for the succinct feedback. It is refreshing to see that all items are not in must-have category :-)
Dinesh
06-10-2009 1:40 AM |
BenHayat: I think this is a decision that community and RIA team need to come to consensus, as which way to go to. The next generation of VS10, WCF, WF, WPF, Astoria, EF, RIA and etc., have such a strong dependency on .Net 4.0, that one needs to decide to stay with 3.5 or 4.0. Perhaps this is a good time for the team to get a "True" measure on this subject.
Ben, apart from being generally knowledgeable about Silverlight and .NET RIA Services really has a good point here. I will use his post to illustrate what we are struggling with
But above all, thanks for taking the time to try out RIA Services and Silverlight CTPs and passionate advocacy of the features you believe in. We are listening and figuring out how to shape our plans - even if we can't do all you would like us to.
06-10-2009 1:48 AM |
MS has obviously chosen not to publicize this but you CAN use ria services with 2010. 2010 doesn't come with the tool support but you can add the project link manually.
<LinkedServerProject>..\{web project path}.csproj</LinkedServerProject>
so far I only tested service operations but i'm sure it works for the whole 9. Commence conversion 2010!
06-10-2009 1:49 AM |
@MrDave,
Thanks for the feedback and you have a fair point about knowing what back-level support is going to cost.
The team is heads down working on July CTP so I don't have full design/cost info yet. But based on prior work I would say that we would lose a couple of medium-large sized features to pay for back-level .NET support and possibly more for back-level VS-support (disclaimer: these are my somewhat wild guesses). I don't know which features will be near the cut line until we assess the current and July CTP feedback. In fact a goal of this thread was to get a sense of what matters most so we can better prioritize and we are getting good feedback.
bigbadwolf
12 Posts
06-10-2009 2:44 AM |
Since you are asking for feedback...
I have only one request: improve the Exception Handling. Currently an exception that is raised on the server side (especially the ones raised by [RequiresAuthentication()] for example) do not make it back to the client side. It just looks that nothing has happened. You can find the exception in the arguments of the Loaded (or Submitted) events, but it would be nice if the exception just was thrown (or at least that we have the option to do this).
06-10-2009 3:18 AM |
shan_mcarthur@spamcop.net: #4 - using Domain Service in ASP.NET, AJAX, and other dynamic data applications - this feature should be considered critical. I would recommend that RIA be designed with AJAX and Silverlight side-by-side to ensure that we don't get into a pattern that we cannot get out of. ie: the current design of RIA requires compiling code and does not expose the metadata through the service - this will make using AJAX and other frameworks very difficult. Please reconsider adding AJAX and ASP.NET to the list of technologies to support as soon as you can in the roadmap. Knowing that you are just putting the final touches on the July CTP, the next ship date after that should be considered for AJAX and ASP.NET, and it should come no later than PDC to ensure that it has a good reception from developers at the conference. Thanks,Shan
Thanks for the feedback Shan. Are you looking at Ajax support primarily as an insurance policy or pattern/skill sharing or as a feature to have multiple clients of the same DomainService? I would be curious to know more about your scenarios if it is multiple clients for the same DomainService.
roncain
434 points
88 Posts
06-10-2009 8:37 AM |
What are your requirements for the command line utility?
The code-generation part of RIA Services is an MSBuild custom task that technically requires only MSBuild and .NET 3.5 to create the client proxy classes. In past CTP's, there was a static dependency on some VS assemblies to allow the same task to communicate with VS when the IDE was hosting the build, but those static dependencies have been removed specifically to enable scenarios for building on machines without VS installed, such as build labs.
Our own unit and functional tests build outside the VS IDE. We literally launch a CMD window that does "msbuild stuff.sln" to build all our internal code as well as our sample applications.
Granted, this still represents a dependency on MSBuild, but that is our broad strategy for project structure across languages and teams, and it is independent of an IDE.
Does that story work for you, or are there other things you need? You could certainly view and modify the files in any IDE you choose, but it would be your responsibility to invoke MSBuild to regenerate the client proxy classes when appropriate.
Ron Cain [MSFT]
jasonbst...
6 points
7 Posts
06-10-2009 8:44 AM |
I would rather get some good integration with EF4 and some great designer tools in VS2010 than compatibility with 3.5 and VS2008.
Our usage will primarily be EF4 hopefully with POCO objects so that we can lean towards a mored DDD approach and a Silverlight client.
Thanks for giving us the opportunity to provide some feedback Dinesh.
06-10-2009 9:01 AM |
Moemeka: YOU ARE MY HERO! THANK YOU so much for pointing this out! I will be upgrading today. :D :D :D
Dinesh: Thank you for being interactive with our requests and not boarding yourself up as some teams in Microsoft tend to do after announcements are made.
My feedback is as follows:
Anyways, despite these two issues, I am lockstep behind you. This is the future and I've been slaving away at getting this code to work properly in my framework. Soon... very soon. :D
06-10-2009 9:08 AM |
In my opinion it is better to invest in new features so RIA Services v1 for Silverlight becomes a mature product. Please make sure RIA Services v1 will be better than the first version of the Entity Framework. EF v1 looks great but there are a lot of limitations when developing large scale applications. EF4 solves most of these problems but in meanwhile we have been done a lot of plumbing with EF v1.
Productivity, a lot of features and quality are the most important. So back-level support for .NET or VS is not so important for me. I will force my hosting provider to install what is needed to run our software.
adriano....
16 points
26 Posts
06-10-2009 9:14 AM |
We already have an ASP.NET DomainDataSource. It would be nice to see a version of the client components for WPF.
06-10-2009 2:52 PM |
roncain: What are your requirements for the command line utility? The code-generation part of RIA Services is an MSBuild custom task that technically requires only MSBuild and .NET 3.5 to create the client proxy classes. In past CTP's, there was a static dependency on some VS assemblies to allow the same task to communicate with VS when the IDE was hosting the build, but those static dependencies have been removed specifically to enable scenarios for building on machines without VS installed, such as build labs. Our own unit and functional tests build outside the VS IDE. We literally launch a CMD window that does "msbuild stuff.sln" to build all our internal code as well as our sample applications. Granted, this still represents a dependency on MSBuild, but that is our broad strategy for project structure across languages and teams, and it is independent of an IDE. Does that story work for you, or are there other things you need? You could certainly view and modify the files in any IDE you choose, but it would be your responsibility to invoke MSBuild to regenerate the client proxy classes when appropriate. Ron Cain [MSFT]
Hi,
that works perfectly. Thank you for the response. I naturally assumed that there was some IDE dependency when Tim Heuer's post declared that ria could not be used with 2010. Is there any pitfall to using the v4.0 version of msbuild?
06-10-2009 4:02 PM |
MichaelDBang:Moemeka: YOU ARE MY HERO! THANK YOU so much for pointing this out! I will be upgrading today. :D :D :D
dont thank me just yet. You should know that vs2010 as several major 'quirks' when working with silverlight projects. Its a great technology preview but you might spend more of your time tracking down the source of bizzare happenings than actually developing. I made the mistake of upgrading a project and having been suffering through things since. The most popular problem I encounter? Well every once in a while perfectly fine applications will just stop building for bizzare reasons. The last one I got was because the IDE decided to stop fully qualifying Effects in the g.cs generated file. Since system.windows.media.effects is not in teh default xaml namespace my projects just started failing. No matter what I did I could not resolve the problem. I finally restarted vs2010 and everything started working fine. Just an FYI.
coleydog182
4 points
2 Posts
06-11-2009 12:25 AM |
From the 'RIA Services May 09.pdf' document.
5.9.2 IChangeTracking/IRevertibleChangeTracking
Entity, EntityList and EntityContainer all implement these interfaces explicitly.
These interfaces are used during client changeset processing and are not intended to be used directly by application developers. As with IEditableObject, these are the interfaces general data controls like DataForm use to interact with the objects they’re bound to (without depending on the EntityType). For example, DataForm uses IChangeTracking.IsChanged to determine if a bound entity has been modified. Entity, EntityList and EntityContainer have a HasChanges member that is public, which delegates to the IsChanged implementation.
This is all very good but suppose the user makes multiple changes and submits the changes via a button or whatever. Then also suppose that one of the changed entities is rejected server side because of maybe a concurrency issue.It would be really useful if the data change state could be undone for that entity via a simple select and undo triggering a call to a reject changes method rather than re-reading the specific entity or seperately tracking changed properties. All the information is already there under the hood.Typically a user gets a set of data, makes some changes, submits the changes. If one of the changed entities is rejected the user would typically want to undo the changes for that entity and re-submit the remaining changes. Later would select the unchanged entity and repeat the change.This under the hood access was openly provided with DataSets and DataTables. I believe the same is absolutely necessary for RIA services.
06-11-2009 8:37 AM |
Regarding the use of MSBuild and a CMD line tool...
moemeka: Hi, that works perfectly. Thank you for the response. I naturally assumed that there was some IDE dependency when Tim Heuer's post declared that ria could not be used with 2010. Is there any pitfall to using the v4.0 version of msbuild?
I'm not aware of any pitfalls using v4.0 of msbuild, but to be honest we're just now looking at the issues with working with both .Net 3.5 and 4.0. This build task is critical to our code-gen story, so we'd be interested to hear about any issues you discover.
... ron
Aquilax
37 Posts
06-11-2009 11:12 AM |
Because the release is for 2010 I don't see the need to support .NET 3.5 SP1 and VS 2008 SP1, is much better to support VS 2010 and .NET 4.0
I prefer RESTful services and I can only be agree with an aligment with ADO.NET Data Services
IMO ASP.NET MVC is ideal for internet application whereas WebForms are more for intranet application. Because RIA means Rich Internet Application, I see it better coupled with MVC.
Generated methods name are nice, but when you have to work in a dynamic way you have to use reflection to access those methods, which IMO is not very nice. I would prefer the introduction of a generic interface to access them.
public sealed partial class DomainService1 : DomainContext, IServiceEntity<Product>{ IQueryable IServiceEntity<Product>.Queryable{get{return DomainService1.ProductsQuery;}} EntityList IServiceEntity<Product>.EntityList{get{return this.Products;}} void IServiceEntity<Product>.Load(){this.LoadProduct();} ... void IServiceEntity<Product>.SubmitChanges(){this.SubmitProduct();} ...}
Regards
06-11-2009 11:21 AM |
Aquilax is right on, and goes back to my point about leveraging WCF and interfaces for all the heavy lifting, IMHO...
06-11-2009 12:03 PM |
MichaelDBang: I'm a little worried about the overall direction of RIASs. It really appears that it is reinventing the wheel again and replacing a lot of what WCF has covered. Are there plans to incorporate more WCF functionality? As bigbadwolf mentions, Exception Handling is a little spotty right now. I've had to make some crazy adjustments to my code to enable the WCF Exception Handling awesomeness that is already in the Enterprise Library (I've created a ExceptionShieldingDomainService, heh). The overall feel of the framework is that it is trying to pull away from WCF. I'd encourage more interaction and leveraging of WCF and its power . But that's just me. :)
I'm a little worried about the overall direction of RIASs. It really appears that it is reinventing the wheel again and replacing a lot of what WCF has covered. Are there plans to incorporate more WCF functionality? As bigbadwolf mentions, Exception Handling is a little spotty right now. I've had to make some crazy adjustments to my code to enable the WCF Exception Handling awesomeness that is already in the Enterprise Library (I've created a ExceptionShieldingDomainService, heh). The overall feel of the framework is that it is trying to pull away from WCF. I'd encourage more interaction and leveraging of WCF and its power . But that's just me. :)
I feel like a broken record here but I think people are just not seeing the big picture. The pieces you are complaining about are just temporary scaffolding used to hold RIA Services together while it is being built. Look back at the roadmap, in the PDC timeframe that temporary scaffolding is finally getting completely replaced by ADO.NET Data Services. Kind of like the keystone of a bridge getting slotted into place so that the bridge becomes self supporting allowing the old scaffolding to be taken down. RIA Services is moving towards WCF, not pulling away.
06-11-2009 12:12 PM |
Sounds like there's a need for a FAQ or resources somewhere that outlines these valuable pieces of information so that we can read before complaining about them. :)
As far as scaffolding goes, I've had my nose in this codebase for a couple weeks now, and it is extensive. It seems to me that it is more than just scaffolding, and that a lot of time could have been saved from the get-go by simply leveraging WCF in all its glory. It's a mature framework that has been around and flirts a lot with the communication issues that RIASs attempts to solve...
06-11-2009 1:25 PM |
MichaelDBang: Sounds like there's a need for a FAQ or resources somewhere that outlines these valuable pieces of information so that we can read before complaining about them. :) As far as scaffolding goes, I've had my nose in this codebase for a couple weeks now, and it is extensive. It seems to me that it is more than just scaffolding, and that a lot of time could have been saved from the get-go by simply leveraging WCF in all its glory. It's a mature framework that has been around and flirts a lot with the communication issues that RIASs attempts to solve...
I want to be sure that I didn't overstate things for you. The temporary scaffolding I was referring to was the current HttpHandler that is hosting the DomainService. It is very simple and I fully expect things like exception handling to improve once a richer foundation is put in place for the actual communication. If your complaint is on the fundamentals on how RIA Services works then no, that isn't scaffolding.
Lex Lavn...
1 Posts
06-11-2009 4:42 PM |
1. Generic data access without hard-coded proxies. Like DomainService.GetTable(Type)
2. VS2010 support is nice, but VS2008 support is much more important. We (developers) are using it right now with lots of plugins, addins, extensions. VS2010 will be usable at least after 1 year since its release, 'cos VS.NET ecosystem needs some time to catch up. VS.NET without VCS plugins, third-party refactoring tools, etc is barely usefull.
3. .NET 3.5SP1 support is VERY important, because it is .NET platform for next few years. Nobody knows .NET 4 release date, in production it will be accepted after at least first service pack, which is probably in 3 years from now. Our products releases lay much closer in future.
Nobody argues that .NET 4 is faster, higher, stronger, but in practice, developers are really dependent on that.NET platform what their customers actually use and can support. For next few years it will be .NET 3.5 SP1.
Dinesh, if you like that RIA services be actually used, it MUST be compatible with current development tools & platforms.
My 2 cents...
06-12-2009 9:44 AM |
@Dinesh
VS2008 is actually not a big deal for us. We would gladly upgrade to VS2010 if it meant getting RIA Services out the door sooner. We don't care about better IDE support as much as earlier ship date and support for 3.5SP1. To me, things like drag and drop databinding seems like a non issue for people who are already have production apps running.
Our hosting provider (Rackspace Cloud aka mosso) took several months to move from 3.5 to 3.5sp1. Since sp1 was additive, we could just add the new .dlls to our bin directories ourselves and get the new Astoria/WCF stuff. If a similar work around was possible with RIA, than I would say go ahead and focus on 4.0. If not, requiring 4.0 would be effectively moving the date at which we could use any version of RIA Services out by several months for most(?) hosted developers.
The current state of RIA Services is already a big step forward from the current stack of hacks we have to use now to get data binding and change tracking to work with Astoria.
We'd like to see fewer new fancy features and an earlier release date with support for 3.5sp1 (although I understand those may be conflicting goals for you guys).
Thanks for keeping us in the loop!
06-12-2009 10:06 AM |
zmorris:We'd like to see fewer new fancy features and an earlier release date with support for 3.5sp1 (although I understand those may be conflicting goals for you guys).
06-12-2009 10:50 AM |
zmorris: The current state of RIA Services is already a big step forward from the current stack of hacks we have to use now to get data binding and change tracking to work with Astoria. We'd like to see fewer new fancy features and an earlier release date with support for 3.5sp1
We'd like to see fewer new fancy features and an earlier release date with support for 3.5sp1
Yes, I think that summarises what I was trying to say as well.
06-12-2009 12:41 PM |
BenHayat: zmorris:We'd like to see fewer new fancy features and an earlier release date with support for 3.5sp1 (although I understand those may be conflicting goals for you guys). @Dinesh and Zmorris; This is an interesting thought; I was recently having a conversation with Colin, where he expressed his desire in a similar fashion which I had been thinking about. And now this comment from Zmorris, helps to come up with a proposal that might be able to make both groups happy. How about, if the team can give us a version of RIA that still works on VS2008/3.5sp1 and is functional enough that developers can produce running apps for several months (so their clients can move to .Net 4.0) and then eventually move to RIA V1. For example this version can be available at PDC time as beta, which won't have all the bells & whistles of VS10, but it's still functional. And then the team can carry on with V1 with VS10/.Net4.0 for those who can use that setup. So I guess maybe the team can shift certain features around (that are none VS10/.Net4.0 dependent) for PDC time and then engage with VS10 features after PDC. Would this work Dinesh? Thanks!
@zmorris and @Ben,
You have good points about the importance of 3.5 SP1 over VS 2008 and the need for a good transition story. The latter was a goal from the beginning (sorry, didn't really get that clear in my original post) and we are looking into the former for V1 (no firm plans yet as the team is focused on July CTP)
micmit
44 points
45 Posts
06-25-2009 7:52 PM |
As for integration and alignment with ADO.Net Data Services
1. Is July .Net RIA CTP going to work with ADO.Net Data Services 1.5 CTP ?
2. May we say for PDC beta where inner works will change ( ADO.Net Data Services will become underlying protocol ) it shouldn't significantly break this alignment part of interface from July CTP.
06-25-2009 8:19 PM |
@micmit
We are planning some very early integration experiences with ADO.NET Data Services in July CTP - more to show the direction, get feedback and internally build the right code-base for planned migration in PDC timeframe. Since its implementation started relatively recently, it will be far less baked than the March/May RIA Services CTP features. Specifically
Yes. RIA Services CTP MSI will carry some additional ADO.NET Data Services DLLs that are modified versions of 1.5 CTP. However you should be able to use both (Data Services 1.5 and RIA Services July CTP) on the same machine.
As always, we will take care of what we know to avoid/minimize breaking changes while being clear that there could be breaking changes from CTP to CTP or CTP to RTW. There are no known/planned breaking changes in the alignment part. Frankly in case of this alignment work, we are early in scope of things you can do so play around with it and give us feedback about what parts of the story are interesting and the general design issues you find rather than assuming compat and doing serious work at this point with the alignment bits.
06-25-2009 8:39 PM |
Dinesh Kulkarni: @micmit We are planning some very early integration experiences with ADO.NET Data Services in July CTP - more to show the direction, get feedback and internally build the right code-base for planned migration in PDC timeframe. Since its implementation started relatively recently, it will be far less baked than the March/May RIA Services CTP features. Specifically 1. Is July .Net RIA CTP going to work with ADO.Net Data Services 1.5 CTP ? Yes. RIA Services CTP MSI will carry some additional ADO.NET Data Services DLLs that are modified versions of 1.5 CTP. However you should be able to use both (Data Services 1.5 and RIA Services July CTP) on the same machine. 2. May we say for PDC beta where inner works will change ( ADO.Net Data Services will become underlying protocol ) it shouldn't significantly break this alignment part of interface from July CTP. As always, we will take care of what we know to avoid/minimize breaking changes while being clear that there could be breaking changes from CTP to CTP or CTP to RTW. There are no known/planned breaking changes in the alignment part. Frankly in case of this alignment work, we are early in scope of things you can do so play around with it and give us feedback about what parts of the story are interesting and the general design issues you find rather than assuming compat and doing serious work at this point with the alignment bits.
Dinesh, is the PDC timeframe plan that ADO.Net Data Services completely replaces the existing communication method or that it becomes an option? I have been assuming that it replaces which makes it easier to explain to people just what RIA Services is.
06-25-2009 9:16 PM |
Dinesh, is the PDC timeframe plan that ADO.Net Data Services completely replaces the existing communication method or that it becomes an option? I have been assuming that it replaces which makes it easier to explain to people just what RIA Services is. -Colin Blair
-Colin Blair
The plan is to replace the current RIA Services protocol implementation with the ADO.NET Data Services protocol.
Klinger
1686 points
300 Posts
06-26-2009 4:04 PM |
My questions are:- Will ADO.NET Data Services help with the security story? How?- And, also, is this new communication strategy going to reduce in any way the functionalitywe have now on RIA Services?
Regarding VS 2008, we hope it will be supported, unless this means reduced functionality in .NET Ria Services.
Our application is just a regular forms based data gathering thing. No fancy graphics or animations.We have around 100 tables and many forms.All we need is a secure, reliable and fast way of moving data between the server and the client.We are using SL instead of WPF because we want our app to be accessible on the web, cross platform, and resemble a Windows app as much as possible.
When we started our SL application we looked at WCF and ADO.NET Data Services as alternatives to move data.We decided to go with WCF mostly because of security considerations and control.We could not find a good way of securing ADO.NET Data Services. Maybe we didn't go deep enough.We found that using the message header to carry our security token wasn't that bad and we were happy with that. A side effect of doing that was that we didn't have to worry too muchabout token expiration as it was 100% under our control.Now, we are using RIA Services (much less work than WCF).We changed the way we handle security (no message header).We are using forms authentication and auth cookie. We hope the security story will improve soon.
.NET Ria Services is great because it does not get in our way, for the most part.We hope it will only get better on that.
06-26-2009 4:40 PM |
Klinger: My questions are:- Will ADO.NET Data Services help with the security story? How?- And, also, is this new communication strategy going to reduce in any way the functionalitywe have now on RIA Services?
What security problems were you having with ADO.NET Data Services previously? Since you are using forms authentication security should have been built in.
06-27-2009 10:07 PM |
Colin,
We could not find a good/simple way for securing ADO.NET Data Services other than using Forms Auth
with cookies (opening the door for "cookie reply" attack) and also have to deal with cookie expiration.
WCF appeared to be easier to secure, even in SL. Now, in SL3, it's even easier and more robust.
kylemc
1482 points
255 Posts
06-29-2009 10:52 AM |
I'd appreciate it if you'd elaborate a little. As far as I know, ADO.NET supports the same transport security and authorization options as WCF. I'm not sure what the ADO.NET message security story is. Is it more difficult to configure ADO.NET security, or is there something significant that's missing?
Kyle
06-29-2009 7:18 PM |
Kyle,It appeared to us that intercepting the message header and adding what we wanted to it (user/pwd, token) was a simple and good way to go.It wans't objvious how to do the same on ADO.NET data services. That’s all.Again, we didn’t explore this option too much.
The WCF solution was working in no time. We also didn't want to move all the logic to the client. WCF is more work, but it also meant more control and somehow it appeared to be simpler for us to understand. For instance:- Sending only the data needed: Use data contracts or serialize the object (json?) and send it as string;- Sharing code between server and client: Use links and make sure it compiles on both sides- Placing business logic and validation: Lots of options here.- Returning results from server (exceptions for instance): Just always return something that can be inspected. (Simpler now with SL3).NET RIA Services is a great replacement for what we were doing in almost all aspects. It somehow fits well in our mental model.We found it to be predictable (once you know the rules), controllable and we can understand it. The only thing we don’t know how to do yet is how to intercept the messages and add our token to it (on both sides). Is it something we even should be doing?
It looks like a decision has been made regarding using ADO.NET Data Services.So, going back to my original questions:How is ADO.NET Data Services going to improve .NET RIA Services compared to what we have now? What impact should we expect?Is it going to increase complexity (one more thing to keep in sync)? Are we goind to lose functionality or control on .NET RIA Services?Is it going to be transparent?
06-30-2009 9:56 AM |
Thanks for the feedback. That clears things up a bit. As you noticed, our current transport layer doesn't support message-level security. Again, I'm not sure whether ADO.NET Data Services supports it, but my guess is that it does not. The impact of the switch should mostly be transparent. I don't think you'll lose any functionality, but you may not gain any new security features either.
As far as I've heard, I don't think message security is any more secure than transport security. I'm sure each has its vulnerabilities if used incorrectly. Luckily, the ASP.NET integration makes it pretty to use transport security correctly. Hope that helps.
Jantiff
07-10-2009 5:11 AM |
today with the release of Silverlight 3 I tried to update my project, but the Ria Services Preview won't work with SL 3 Release.
I looked for a new version of RIA Services Preview and downloaded the version of 09-07-09, but when I try to install it, it says Silverlight 3 BETA is missing. :(
Any suggestions when this will be fixed?
Thanks,
Marc
leifre
11 points
19 Posts
07-10-2009 6:45 AM |
Im running into the same issue. Installed the Silverlight3 RTW along with toolkit and now I cant use RIA which is a major problem as you can imagine. DO you have any timetable for this getting resolved? I read that there is supposed to be another release of RIA this month. Is this true and will it fix the problem. Right now, Im dead in the water.
steveprov
07-10-2009 6:48 AM |
Same Issue here trying to get my Production Machine all setup with SL3. Very frustrating.
mohnani....
323 points
66 Posts
07-10-2009 7:07 AM |
What is the size of the MSI you downloaded?
07-10-2009 7:15 AM |
4,322,304 bytes taken from the file Properties dialog
07-10-2009 7:16 AM |
RiaServices.msi with 4.12 MB
07-10-2009 7:19 AM |
Silverlight3_Tools.exe - 32.2 MB (33,813,856 bytes)
Blend_Trial_en.exe - 71.1 MB (74,632,544 bytes)
Silverlight_3_Toolkit_July_2009.msi - 13.1 MB (13,801,472 bytes)
the standalone silverlight player wont install with the dev one from the tools installed..but i even tried removing the dev version and using this sl3 and it wont work either in Visual Studio b/c its not a dev version:
Silverlight.exe (silverlight 3 rtw) 4.69 MB (4,927,864 bytes)
07-10-2009 7:29 AM |
Downloaded the Riaservices.msi from
http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=76bb3a07-3846-4564-b0c3-27972bcaabce&displaylang=en
Digital Signatures Timestamp is May, 11th, 2009
07-10-2009 7:30 AM |
The RiaServices July preview bits are making their way to all the servers.
The May2009 preview msi was about 4,221 KB.
Its just a matter of time when the bits make it to all the server. July 09 Preview is about 5.68 megs.
07-10-2009 7:43 AM |
Thanks very much for the quick answers - and I managed to download the new version just now from the above link.
Tried it out and it works, phew. :)
07-10-2009 12:30 PM |
Let me second that thought...Its real nice to have such quick responses and a resolution so quickly. It also keeps me from having a heart attack as well ;)
keoz
20 points
20 Posts
07-20-2009 5:43 PM |
I just want to point out that you guys in ria services team are doing amazing job congratulations every day i see that choosing MS was the right choice since 2 years ago and bet for new technologies has been always the right path
Anyway is nice to see that RIA services is going to take a leap forward to the evolution of EF and Data Services that's the way to go no matter what enterprise is, using this technologies is a must
So i think you have to go forward with .NET 4 compatibility since going with 3.5 is a step backward and RIAS would look like just another wrapper for actual features on .NET and geting the .NET 4 features out of scene for complete so that's not the way to go
And finally come on we developers have no problem using VS 2010 since its going to support .NET 3.5 still so there is no point in saying you people want VS 2008 compatibility at all, that's is using no comon sense, and in the other hand if you say enterprises are not upgrading to .NET 4 is also lame since .NET 3.5 and .NET 4 can coexist in any machine and installing .NET 4 is just a matter of that! installing it, you don't have to complain about enterprises not moving in and if an enterprise does complain you should have the capacity to convince them to upgrade and that it won't do any hurt like they always are thinking, besides there is the upgradability of applications that is gonna be very straightforward since .NET 4 features are not reinventing the core technologies like WPF, WCF etc so moving applications to .NET 4 will be just cost effective, and if you complain about catching up with .NET 4 features well that's no point either since it should be like upgrading knowledge from .NET 3.0 to .NET 3.5 again it's just an upgrade not a whole new difference on technologies like was .NET 2.0 to .NET 3.0 so better get up to date :)
larserik
3 points
08-16-2009 2:01 PM |
There is one major backdraw with RIA as I see - you need to change your core domainmodel (...the <Entity>.shared.cs class+attribute tagging) in order to generate custom clientside code.
I really don't want to touch my core domainmodel project at all. My domainmodel projects exists today as a regular .net library project - and I don't want to mess it up with shared code and attribute tags ! I would like to have these client specific stuff in the Web project or in a silverlight library. I tend to think of the RIA domainservice as an application specific / context dependent thing . Often I would like to use the same domain entities in another context with a different exposure of clientside-code and validations.
Maybe using WCF or ADO.net astoria as layer behind RIA will solve this problem - but I am not sure. But then again you lose all the advantages of using RIA in the first place. Using pure DTO is another solution.
08-16-2009 11:03 PM |
larserik: There is one major backdraw with RIA as I see - you need to change your core domainmodel (...the <Entity>.shared.cs class+attribute tagging) in order to generate custom clientside code.
Just to throw out my own thoughts on this, I think this is a transitionary period on the attribute part of things. The attributes were originally created for ASP.NET Dynamic Data and are now being used by RIA Services, but they are really about rules within the model, not the data access system. Therefore, I think it is better to think of the rule attributes as being part of the model. I would be surprised if some future version of EF doesn't move the attribute editing into the EDMX file and eliminating the need for the metadata file when using the Entity Framework.
The reason I said this is a transitionary period on the attributes is that a few of the attributes (Include and Exclude) don't really fit into the idea of the rules being part of the model. I don't have an answer for that one.
yashgt
08-20-2009 12:08 AM |
Hi,The class System.Web.DomainServices.Tools.VisualStudio.DomainServiceClassWizard implements the wizard which gets invoked when a new Domain Service is to be added. The namespace contains other wizards that implement the IWizard interface and these classes are defined as public. Only the class DomainServiceClassWizard is defined as internal.
It will be useful if this class is defined as public so that people can derive their own wizards from it and thereby control the structure of the class that gets created.
Thanks,Yash
08-20-2009 8:18 AM |
yashgt: It will be useful if this class is defined as public so that people can derive their own wizards from it and thereby control the structure of the class that gets created.
It is an interesting idea, but we're trying to minimize the public surface area we commit to support in future versions, and to minimize the Test matrix for extensibility points (imagine we unseal this class and someone undoes some project changes we assume succeeded). We've actually done some of this in house, and it can get difficult to define and test the contracts for what the wizard does.
What kinds of extensibility were you considering? Adding different references? Altering the project structure?
08-20-2009 9:57 AM |
We would like to customize the generated the Domain Service class, such that it is partial and it invokes a few partial methods that we define. We are not able to customize the Item Template at Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Web\1033\BusinessLogic.zip as we are not able to capture the name of the class, entity chosen ,etc. Had these been exposed as Custom Parameters in the template we could have done something there.
Yash
08-20-2009 10:18 AM |
yashgt: We would like to customize the generated the Domain Service class, such that it is partial and it invokes a few partial methods that we define. We are not able to customize the Item Template at Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Web\1033\BusinessLogic.zip as we are not able to capture the name of the class, entity chosen ,etc. Had these been exposed as Custom Parameters in the template we could have done something there.
Adding partial to the class definition would be a very good thing, and if there was some way for the wizard to detect if the named DomainService already exists while it is checking for metadata and not generate the EnableClientAccessAttribute on the additional partial classes that would be a huge help.
I don't agree with the partial methods. You have to take ownership of the DomainService, the wizard is only generating a template for your DomainService. From a technical standpoint, anything in the wizard generated DomainService could just as easily have been done at runtime like how ADO.NET Data Services does it. The only reason that the DomainService exists the way it does is for you to make changes to it.
08-20-2009 10:36 AM |
ColinBlair: Adding partial to the class definition would be a very good thing, and if there was some way for the wizard to detect if the named DomainService already exists while it is checking for metadata and not generate the EnableClientAccessAttribute on the additional partial classes that would be a huge help.
Interesting -- both requests for wizard extensibility are focused on what I might call "code gen extensibility", albeit at a special point in the generation process. We're considering a T4 approach for the next version with a good set of extensible T4 templates (i.e. to let you override specific chunks rather than taking ownership of a single monolithic template). I had not considered triggering this extensibility at the point a DomainService is generated by a wizard, but it sounds reasonable to add to the scenarios to consider.
To be clear, I hear 2 different code-gen needs -- the ability to T4'ize the generation of DomainServices, including during template creation. And the ability to T4'ize the generated proxy classes during a build. All I can promise is that we will add these to our code-gen-extensibility scenarios as we plan the next version.
08-20-2009 11:00 AM |
roncain: To be clear, I hear 2 different code-gen needs -- the ability to T4'ize the generation of DomainServices, including during template creation. And the ability to T4'ize the generated proxy classes during a build. All I can promise is that we will add these to our code-gen-extensibility scenarios as we plan the next version.
YESSSSSSSS!!! Great to hear.
08-20-2009 11:44 AM |
roncain: ColinBlair: Adding partial to the class definition would be a very good thing, and if there was some way for the wizard to detect if the named DomainService already exists while it is checking for metadata and not generate the EnableClientAccessAttribute on the additional partial classes that would be a huge help. Interesting -- both requests for wizard extensibility are focused on what I might call "code gen extensibility", albeit at a special point in the generation process. We're considering a T4 approach for the next version with a good set of extensible T4 templates (i.e. to let you override specific chunks rather than taking ownership of a single monolithic template). I had not considered triggering this extensibility at the point a DomainService is generated by a wizard, but it sounds reasonable to add to the scenarios to consider.
This is great news for future versions of RIA Services. I do love T4 templates.
08-21-2009 5:40 AM |
A DomainService class exposes a DomainServiceDescription object that contains the list of operations exposed by the DomainService and DomainOperationEntries. This helps frameworks like ASP .NET Dynamic Data to figure out the names of methods in the doamin service.
We are working on building something similar to Dynamic Data, but on the client side in a Silverlight application which uses RIA Domain Services. It would be useful to have the list of operations and rest of the description of the DomainContext using something like DomainContext.Description, which would emit DomainOperationEntries just as it does on the server.
Casimodo72
301 points
159 Posts
09-14-2009 8:38 AM |
@roncain "We're considering a T4 approach for the next version with a good set of extensible T4 templates (i.e. to let you override specific chunks rather than taking ownership of a single monolithic template)"
I dunno much about T4, but it would be great if those T4 templates could be designedso that one has full control over the generation process."let you override specific chunks" sounds a bit like the current CodeProcessor approach,which is quite limited, since one can only post-process the CodeDom that isalways generated by default.E.g. currently, when the a TypeDescriptionProvider is set for a domain class,there's no way to stop the processor from applying it. All one could do is remove all thegenerated attributes and apply the TypeDescriptionProvider's information a second time,without being able to reuse any of your attribute-generating code.I.e. the stage at which the desired custom behaviour should havebeen applied, namely at attribute aquisition and merge time, is not accessible andleads to funky hacks.The following would be nice:1) Let me customize standard stages in the transformation pipe. 2) Let me inject new stages (e.g. post-processing, pre-processing, etc.) freely.3) Let me have access to a public library for doing standard stuff. I.e. it's nice to know that I can customize something by overriding it, but mostly you realize that if you just want to customize a tiny 10% of of a thingy, you need to reimplement the other standard 90% without being able to just call the standard code - because it's internal. E.g. I would be very thankfull for a method in the library, which generates an [Attribute(myPositionalArg, Name=myNamedArg)] by giving it an instance of an Attribute. As already mentioned, I dunno much about T4 and cannot foreseewhat is meant with "let you override specific chunks",so this post might not apply.Regards,Kasimier
09-14-2009 9:06 AM |
Casimodo72:I dunno much about T4, but it would be great if those T4 templates could be designed...
Thanks for the suggestions. The "override specific chunks" was a fuzzy way to say what you said. We recognize most developers want to just tweak 10% (or less) and let the other 90% be handled by the default implementation. Other developers may want to swap out everything. So our challenge will be to offer extensible ways to do that. Key to that will be a well factored set of T4 templates with good extensibility built-in, operating over a simple object model over the metadata of the domain services.
From the discussions above, you can see we've also heard suggestions about respecting even the order of items in the metadata so that we don't randomize the order of entities or methods the developer may have grouped. All these factors will go into the design.
Yes, the helper classes will be part of this story -- but it will be important that even the helpers are extensible. The example #3 you gave is actually quite challenging for the general case, as you no doubt have already discovered.
At this point, one important aspect of our T4 story is hearing suggestions like yours and the ones above. All of these will help mold the design.
Ron Can
09-15-2009 3:11 PM |
This sounds very good.
Regarding (3):1) I currently cannot think of an automated way to generate attribute initializations without knowing exactly the internals of the attribute's type. a) If the attribute has a default constructor, one could generate the initialization with named arguments resembling all public properties (and the values of those) of the attribute. - This does not always work. E.g. the DisplayAttribute wants its GetShortName() to be called, rather than its ShortName property in order to perform a lookup on its ResourceType. b) If the attribute doesn't have a default constructor, thus wants positional arguments, then I need to know what properties at what position of the attribute should be used as positional arguments. c) I need to know the default values of the attribute's properties to avoid to flood the initialization with unneeded property setters. Currently I assume that a generation can only be performed when using some kind of description of the attribute's type, or by coding dedicated transformations for each known attribute type. 2) AFAIK, only a specific set of known attributes on the domain class are generated/regenerated on the client side entity and its properties. E.g. if I annotate my domain class or any of its properties with my new custom attribute "MyDummyAttribute", then this attribute will never be gerated on the entity. 3) I can have my "MyDummyAttribute" transported to the client side though using the "shared" partial classes (those are read-only for the generator).So what I would need is the code you already seem to have in use for the generationof the specific set of known attributes.I currently don't see the need for me to extend that set - but one never knows.Regards,Kasimier
RobertMc...
35 points
22 Posts
10-05-2009 12:59 PM |
It's probably too late for input, but here are my thoughts:
Additionally, it would be great if the generated Silverlight classes mimicked the class hierarchy on the server side! I've designed my server-side class hierarchy very carefully and for very important reasons - having the code generator completely flatten it is very frustrating.
Thank you for the excellent work, even in preview form this is a great tool!
Robert
10-05-2009 2:07 PM |
RobertMcCarter: An absolute MUST is the offline data story (the functionality from the attachable behaviours demonstrated by Nikhil at MIX). I'm really hoping you've got this in for the PDC beta. Support for the M-V-VM pattern is very important
I am not sure about the attachable behavior thing, but the offline data story for RIA Services is pretty good. Taking all of the Entities in the EntityContainer, saving them to isolated storage, and then bringing them back in is pretty easy. I have code on my blog to do that. There was an official Microsoft example showing offline storage as well but it is a lot heavier.
RIA Services is really, really good at MVVM support. BradA has all of the code needed to replicate the parts of the DDS that are worthwhile in your VM code.
10-08-2009 10:04 AM |
Regarding MVVM:
Jeff Handley's EntityCollectionView seems to work with EntityList and EntityCollection, while Brad Abrams' version does not have support for EntityCollection. Could it be made to work on an interface instead?
Would be great if Jeff Handley could also expose something like the (internal to DDS) DomainDataSourceEntityCollection and make the EntityCollectionView work with it. It's really handy to have a collection in between the EntityList.
Regards,
Kasimier
nigelpage
10-14-2009 11:01 PM |
We would like to be able to use the DomainSevice with anything we like and are happy to build adapters if required. Our current needs are: -
We have a current WCF service layer that is used for app integration and need to maintain that, as well as not wanting to duplicate functionality on the server side, so settling on DomainService would be very advantageous. Our current UI standard is WPF, but our intent is to move it all to Silverlight. When we started development Silverlight could not support what we needed, but that is no longer true, so we will take advantage of it.
We also need to be able to expose 'snippets' of functionality embedded in ASP.NET MVC pages, so out of the box integration is also important to us.
Quite frankly, the more plumbing you provide, the less we have to provide, so flexibility on server side usage of DomainSevice is important to us.
Nigel
ringi
10-17-2009 3:27 PM |
I am not yet using Silverlight or RIA services however this is what I would like to see.
I don’t mind being limited to .NET 4 as it is unlikely many people will be using RIA before .NET 4 ships. The short term pain of having to get .NET 4 installed is worth it for the years of benefit that a better RIA will give.
I would like to see match better support for NHibernate including examples. I don’t wish to have to choose between the leading ORM and the leading UI platform…
I would like to see support for WPF, encase I have to switch from Silverlight to WPF at some point.
Having a system like Aps.net dynamic data to generate the 101 simple data admin forms any reel applicant needs would be of great value. (Otherwise part of an application may need to be Asp.net just to use Aps.net dynamic data) However don’t delay version 1 for this.
.NET RIA Services V1 CTPs: current thinking