none
.NET RIA Services V1 CTPs: current thinking

    Question

  • 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

     

    July 2009 CTP
    • This is a preview, not the V1 release. We plan to drop go-live restriction from EULA – still use it at your own risk.
    • Try to get significant known breaking changes (the ones we don’t know about will come later)
    • Feature enhancements (e.g. code-gen hookpoints to add your custom code, improved library support, better shared code support, query for singletons, cleaner user model and better extensibility support for Application Services etc.)
    • Usual fare of bug fixes, API improvements etc
    • Enable a first set of better together experiences with  ADO.NET Data Services (add a DomainService to Data Service for writing app logic / expose DomainService as DataService)

     

    PDC 2009 Beta
    • Additional core feature work (list TBD, under consideration – hierarchy support, presentation model)
    • Work on Visual Studio 2010 / .NET 4 support
      • Drag-drop support for databinding
      • Run in medium trust
    • Move to ADO.NET Data Services as the underlying protocol

     

    First part of 2010: RTW
    • Polish beta release (bugs, perf, stress, security, localization, …)
    • Small design changes / tweaks
    • Keep up with changes in other products

     

    A note on Platforms and tools

    • In each CTP, we will be keeping up with corresponding public Silverlight drops as and when they are scheduled (sorry, I don’t have that schedule)
    • For RTW, we are planning Visual Studio 2010 / .NET 4  as the primary story. Support for previous version TBD (depends on feedback about relative importance / cost / options)

     

    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.

    1. Core features / samples you would want to see
    2. Key end-to-end scenarios that are essential in V1
    3. Support for 
      1. Running on .NET 3.5 SP1 on mid-tier
      2. VS 2008 SP1
    4. Using DomainService in ASP.NET MVC, Ajax, WebForms/Dynamic Data applications
    5. Integration and alignment with ADO.NET Data Services
     Thanks.

     

    Tuesday, June 09, 2009 1:27 AM

Answers

  • @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.

    Thanks.

    Wednesday, June 10, 2009 1:01 AM

All replies

  • 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.

    Tuesday, June 09, 2009 4:08 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:

    • Better code share support so that multiple server projects can be used.
    • An extra option in a Silverlight application/library to specify the corresponding server side assembly. This will avoid a lot of redundant code generation in each Silverlight library.
    • Support for arbitrary types as operation parameters (e.g. Criteria class).
    • Support for arbitrary types as query results (e.g. container class SearchResult with collection of entities and extra properties for options, messages, …)
    • Better support for subcollections which have no parent-child id’s.
    • Many-to-many associations support.
    • A new lightweight kind of DomainDatasource class which can be used in ViewModels (M-V-VM pattern).
    • A better DataFormFieldCombobox control

    Features I would like to see in future versions:

    • Support for EF4.
    • Better support for databinding (DataForm) and M-V-VM scenarios.
    • Better support for authentication and authorization, caching of member profiles and roles, …
    • Internal use of ADO.NET Data Services.
    • Support for Geneva and claims.
    As long that there is no official VS2010 release I would like to see Silverlight 3 and RIA Services working together with VS2008. Once we can move to VS2010 support for VS2008/.NET3.5 is not required for my team.
    Tuesday, June 09, 2009 5:04 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.

    Tuesday, June 09, 2009 7:56 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.

    Tuesday, June 09, 2009 10:09 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.

     

    Tuesday, June 09, 2009 10:16 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.

    zmorris; 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.
    Tuesday, June 09, 2009 10:42 AM
  • 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.

    Tuesday, June 09, 2009 11:43 AM
  • 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.
    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.
    Tuesday, June 09, 2009 12:15 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

    Tuesday, June 09, 2009 12:31 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

     

    Tuesday, June 09, 2009 1:22 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.Big Smile

    Tuesday, June 09, 2009 2:17 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:

    1. Integration with .NET Data Services
    2. Support for .NET 3.5 SP1
    3. Inheritance flattening support that actually works
    4. Support for .NET 4.0/VS2010
    5. Full inheritance support
    6. Other stuff
    7. Support for VS2008
    Tuesday, June 09, 2009 3:18 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!

    Tuesday, June 09, 2009 9:05 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. :)

    Tuesday, June 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. :)

    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.

    Wednesday, June 10, 2009 12:40 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.

    Thanks.

    Wednesday, June 10, 2009 1:01 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).

    Thanks.

     

    Wednesday, June 10, 2009 1:07 AM
  • @jbloomer

    Thanks for the succinct feedback. It is refreshing to see that all items are not in must-have category :-)

    Dinesh

    Wednesday, June 10, 2009 1:13 AM
  • 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

    • First, we hear you on the feedback about value of being able to use existing version. That is why we are trying to figure out the best course here. 
    • There are features in VS 2010 and .NET 4 that we would like to exploit (e.g. I mentioned medium trust support requiring some new feature not available in 3.5SP1). So it is not just about testing on multiple platforms and supporting them (which would itself have substantial costs).
    • The costs of supporting multiple platforms are significant and will not happen without sacrificing significant features (and hence scenarios). Some of you have voiced clear support for prioritization of one over the other which is good to hear (since we can't do all unfortunately).
    • Here I would urge to think of (as indeed some of you have) VS versions separate from the .NET version on the mid-tier machines used for deployment.

    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. 

    Thanks.

     

    Wednesday, June 10, 2009 1:40 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!  

    Wednesday, June 10, 2009 1:48 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.

    Dinesh

    Wednesday, June 10, 2009 1:49 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).

    Thanks.

    Wednesday, June 10, 2009 2:44 AM
  • #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.

    Thanks.

    Dinesh

     

    Wednesday, June 10, 2009 3:18 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]

    Wednesday, June 10, 2009 8:37 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.

    Wednesday, June 10, 2009 8:44 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:

    1. INHERITANCE SUPPORT!  Why on earth is this so poor?  I am shocked to read that "heirarchy support" does NOT mean addressing a GLARING hole in the current framework: Inheritance.  Colin and I have been bitching on the boards about this since its discovery.  I've had to redesign my EDMX models to great discomfort to get them to work in RIASs.  This should never ever be the case; RIASs should work cleanly with any model and should project all entities to the client with no exceptions.
    2. 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. :)

    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

     

    Wednesday, June 10, 2009 9:01 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.

     

    Wednesday, June 10, 2009 9:08 AM
  • We already have an ASP.NET DomainDataSource.  It would be nice to see a version of the client components for WPF.

    Wednesday, June 10, 2009 9:14 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]

     

    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?

    Wednesday, June 10, 2009 2:52 PM
  • Moemeka: YOU ARE MY HERO!  THANK YOU so much for pointing this out!  I will be upgrading today. :D :D :D

    Hi,

      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.

    Wednesday, June 10, 2009 4:02 PM
  • 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.

    Thursday, June 11, 2009 12:25 AM
  • Regarding the use of MSBuild and a CMD line tool... 

    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

    Thursday, June 11, 2009 8:37 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

    Thursday, June 11, 2009 11:12 AM
  • Aquilax is right on, and goes back to my point about leveraging WCF and interfaces for all the heavy lifting, IMHO...

    Thursday, June 11, 2009 11:21 AM
  • 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.

    Thursday, June 11, 2009 12:03 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...

    Thursday, June 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...

    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.

    Thursday, June 11, 2009 1:25 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...

    Thursday, June 11, 2009 4:42 PM
  •  @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!

     

     

    Friday, June 12, 2009 9:44 AM
  • 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!
    Friday, June 12, 2009 10:06 AM
  • 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

     Yes, I think that summarises what I was trying to say as well.

    Friday, June 12, 2009 10:50 AM
  • 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)

    Thanks.

    Dinesh

    Friday, June 12, 2009 12:41 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.


    Thursday, June 25, 2009 7:52 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

    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.

    Thursday, June 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

    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.

    Thursday, June 25, 2009 8:39 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

    The plan is to replace the current RIA Services protocol implementation with the ADO.NET Data Services protocol.

    Thursday, June 25, 2009 9:16 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 functionality
    we 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 much
    about 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.

     

    Friday, June 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 functionality
    we 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.

    Friday, June 26, 2009 4:40 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.

    Klinger

     

     

     

    Saturday, June 27, 2009 10:07 PM
  • 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

    Monday, June 29, 2009 10:52 AM
  • 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?

    Klinger

    Monday, June 29, 2009 7:18 PM
  • 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.

    Kyle

    Tuesday, June 30, 2009 9:56 AM
  • Hi,

    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

    Friday, July 10, 2009 5:11 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.

     

    Friday, July 10, 2009 6:45 AM
  • Same Issue here trying to get my Production Machine all setup with SL3. Very frustrating.

    Friday, July 10, 2009 6:48 AM
  • What is the size of the MSI you downloaded?

    Friday, July 10, 2009 7:07 AM
  • 4,322,304 bytes taken from the file Properties dialog

    Friday, July 10, 2009 7:15 AM
  • RiaServices.msi with 4.12 MB

    Friday, July 10, 2009 7:16 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) 

    Friday, July 10, 2009 7:19 AM
  • Downloaded the Riaservices.msi from

    http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=76bb3a07-3846-4564-b0c3-27972bcaabce&displaylang=en

    Version: 1.0.0.11
    Date Published: 7/9/2009
    Language: English
    Download Size: 5.0 MB - 17.0 MB*

    Digital Signatures Timestamp is May, 11th, 2009

     

    Friday, July 10, 2009 7:29 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.

     

    Friday, July 10, 2009 7:30 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. :) 

    Marc

    Friday, July 10, 2009 7:43 AM
  •  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 ;)

     

    Friday, July 10, 2009 12:30 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 :)

    Monday, July 20, 2009 5:43 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.

    Sunday, August 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.

    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.

    Sunday, August 16, 2009 11:03 PM
  • 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

    Thursday, August 20, 2009 12:08 AM
  • 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?

    Thursday, August 20, 2009 8:18 AM
  • Hi,

    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.

    Thanks,

    Yash 

     

    Thursday, August 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.

    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.

     

    Thursday, August 20, 2009 10:18 AM
  • 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.

    Thursday, August 20, 2009 10:36 AM
  • 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.

    Thursday, August 20, 2009 11:00 AM
  • 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.

    Thursday, August 20, 2009 11:44 AM
  • Hi,

    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.

    Thanks,
    Yash

    Friday, August 21, 2009 5:40 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 designed
    so 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 is
    always 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 the
    generated 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 have
    been applied, namely at attribute aquisition and merge time, is not accessible and
    leads 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 foresee
    what is meant with "let you override specific chunks",
    so this post might not apply.

    Regards,
    Kasimier

    Monday, September 14, 2009 8:38 AM
  • 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

    Monday, September 14, 2009 9:06 AM
  • 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 generation
    of 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

    Tuesday, September 15, 2009 3:11 PM
  • It's probably too late for input, but here are my thoughts:

    • 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 think .NET 3.5 sp1 is a must
    • I really don't care about EF support
    • I don't care about integration with ASP.NET MVC, etc...

    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

    Monday, October 05, 2009 12:59 PM
  • 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.

     

    Monday, October 05, 2009 2:07 PM
  • 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

    Thursday, October 08, 2009 10:04 AM
  • 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: -

    • WCF integration
    • ASP.NET MVC integration

    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.

    Regards,

    Nigel

    Wednesday, October 14, 2009 11:01 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.

     

    Saturday, October 17, 2009 3:27 PM
  • Here goes another vote for the T4 strategy to generate the client side code. This would really make my life easier! Please include that :).

    Monday, January 11, 2010 6:18 AM
  • I'd love to see support for .NET 3.5 since 4.0 is a new CLR and (probably) want be supported by SharePoint 2010 (and other platform products) which limits the applicability of RIA Services to custom built web applications.

    Wednesday, March 24, 2010 7:20 AM