locked
Need help understanding how to generate a proxy for my Sync service RRS feed

  • Question

  • Short version: 

    I am trying to follow the "WebSharingAppDemo" example and using the six-step WCF tutorial as a reference.  I have built and executed a sync service, however, when I attempt to build a proxy to this service using "SvcUtils.exe" I get a source file that (1) won't compile and (2) doesn't look a whole lot like any other service proxy that I have looked at.  Obviously, I don't fully understand the correct process so I am hoping someone who has done this before (and done it right) can enlighten me.

    Longer version:

    Following the "WebSharingAppDemo" example, I have constructed a service named "ProtoSyncService" (I'm still prototyping) and have defined the contract interfaces in the same namespace as the example, only my prototype is written in VB instead of C#.  I have successfully built, deployed, and executed this service.  Next, I used "SvcUtil.exe" to generate the proxy class and the associated configuration file.

    This is where things get interesting.

    The generated file has a lot more content than any example proxy file that I have seen.  It also has over 50 compilation errors, so it is not particularly useful as it is.  Among the more interesting things in the generated file are the following:

    + The output file redeclares my ISqlSyncContract interface.  I have already declared this in the WebSyncContract namespace.

    + I have several comments of the form: CODEGEN: Parameter 'xxx' requires additoinal schema information that cannot be captured using the parameter mode.  The specific attribute is 'System.Xml.XmlElementAttribute'.

    + For some reason, all of the places in my code where I was catching or throwing exception had to be changed from "Exception" to "System.Exception".

    + The tool defined several "Partial Public Class" datatypes that appear to overload my versions of these classes and then decided to change the types of various data members to String (where I had Guid or List(of String), etc.).  Then it also decided to complain about either the properties have "multiple definitions with identical signatures" or "cannot overload each other because they differ only by return types".

    Finally, after about 1000 lines of this stuff, I get to the Partial Public Class SqlSyncContractClient (which looks like the thing I wanted all along) and that class compiles fine.  If I look at other examples, this is the part that seems to matter most and I don't see a lot of this other stuff (class definitions for data objects, etc.)

    So, is there something I am supposed to do differently to get my proxy class generated?  Is there perhaps a command line switch for SvcUtils.exe that I overlooked?  Am I supposed to edit the generated code to throw away a bunch of stuff?  I am at a loss here.  I did this once and got so frustrated with it that I threw it away and started over.  Now I am right back to where I started (but with a better understanding of other aspects of the process), but still with the same basic problem generating the proxy.

    Somebody has already done this and the answers are probably pretty obvious.  I would appreciate any advice or assistance you might be able to offer.

     

    Wednesday, April 7, 2010 2:34 PM

Answers

  • I promised that when I got my WCF interface working I would an update on what I did.  I got it working and here is what I did.

    Short version: Don't even bother with SvcUtil.  It is simply easier and much cleaner to "hand code" your own proxy.

    Longer version:

    Here is the URL to an online presentation on an alternate techique for building a WCF framework, i.e., contracts, service, proxy, etc., in the simplest way possible.

    http://www.dnrtv.com/default.aspx?showNum=122

     

    The basic approach advocated in this presentation is to archtitect your application into specific assemblies each of which focuses on a single aspect.  For example, all contracts and data objects to be passed between clients and the server are in a single assembly.  All code that represents data objects and services common to both the clients and the server are in a single assembly and all proxy classes are in a seperate assembly.

     

    When I reworked my prototype to follow this approach, it quickly revealed what was probably my major problem: I was mixing MSF 1.0 and 2.0 DLLs in my application.  For some reason, using the original approach this was not easily apparent but I think SvcUtil may have been confused by this.  When I started out, I had installed both versions of the sync framework and was apparently able to compile them (for some really odd reason I have not figured out), but SvcUtil was not happy.  So I had to fix that issue and things started working much better.

     

    Using this particular approach, generating a working proxy class is almost trivial.  But this approach does have some limitations.  First, it is relying on the fact that we are using WCF as a transport mechanism and not a public service.  In other words, we own the code on both sides of the interface and must be willing to redeploy both clients and service in the event of changes to the interface.  This is not a major problem for us because we pretty much do that anyway.  Second, I still have to figure out how to properly tune buffer sizes and batching parameters for optimal performance.  I pretty much had to do that anyway, but it is now a little less obvious what my choices are.

     

    The bottom line for us is this: I have successfully built a prototype that covers all major aspects of our sync process (especially the things we need to do that our current implementation cannot do).  Based on this success, we plan to incorporate MSF 2.0 into our application.  MSF 2.0 is not a "perfect" solution, but its imperfections are managable.

     

    However, we still have some work to do, particularly in planning our development and testing efforts before we deploy this capability.  In particular, we are going to carefully plan our test effort and our client deployment.  Our test effort is going to attempt to identify high risk scenarios and then execute appropriate test cases to verify operations in those scenarios.   While we currently have a high degree of confidence in the framework, if it is going to fail we want it to fail as quickly as possible. 

     

    We also want to make sure that client deployment is as efficient and trouble-free as possible.  We have a lot of client systems and do not want to be in the situation of having to walk every single one of them through the upgrade process (we don't have to do that now with upgrades and we want this to be similar).  We also intend to operate the new MSF-based sync process in parallel with our original sync process for at least a little while (they have nothing in common).  That way, if there is some fatal flaw in our design or in the framework itself we are not stuck with a bunch of dead client applications and an angry user community while we are frantically trying to undo the disaster we just inflicted on them.

    Monday, April 12, 2010 5:26 PM

All replies

  • care to share the contracts you defined? some of the issues you have may have something to do with contracts.

    and to answer you're question regarding throwing away a bunch of stuff from teh generated proxy, the answer is yes. Chances are svcutil will generate redundant stuff for Sync Framework related calls but you can simply delete them since they could be resolved against the Sync Framework assemblies you have in reference.

    try using Add Service Reference in VS also, you have some options there for converting Collections to other types, etc...

    Thursday, April 8, 2010 10:58 AM
  • JuneT,

    Thanks for replying to my posting.  While Googling the internet, I came across a 45-minute video that suggested an alternate approach that looks a lot cleaner than using SvcUtil to try to do this, so I am going to take a day or so and give that approach a try.  If it works, I will post a summary.  If not, I will post some code snippets on where I am having problems.  So give me a couple of days and I will get back to this.

     

    Thursday, April 8, 2010 2:10 PM
  • I promised that when I got my WCF interface working I would an update on what I did.  I got it working and here is what I did.

    Short version: Don't even bother with SvcUtil.  It is simply easier and much cleaner to "hand code" your own proxy.

    Longer version:

    Here is the URL to an online presentation on an alternate techique for building a WCF framework, i.e., contracts, service, proxy, etc., in the simplest way possible.

    http://www.dnrtv.com/default.aspx?showNum=122

     

    The basic approach advocated in this presentation is to archtitect your application into specific assemblies each of which focuses on a single aspect.  For example, all contracts and data objects to be passed between clients and the server are in a single assembly.  All code that represents data objects and services common to both the clients and the server are in a single assembly and all proxy classes are in a seperate assembly.

     

    When I reworked my prototype to follow this approach, it quickly revealed what was probably my major problem: I was mixing MSF 1.0 and 2.0 DLLs in my application.  For some reason, using the original approach this was not easily apparent but I think SvcUtil may have been confused by this.  When I started out, I had installed both versions of the sync framework and was apparently able to compile them (for some really odd reason I have not figured out), but SvcUtil was not happy.  So I had to fix that issue and things started working much better.

     

    Using this particular approach, generating a working proxy class is almost trivial.  But this approach does have some limitations.  First, it is relying on the fact that we are using WCF as a transport mechanism and not a public service.  In other words, we own the code on both sides of the interface and must be willing to redeploy both clients and service in the event of changes to the interface.  This is not a major problem for us because we pretty much do that anyway.  Second, I still have to figure out how to properly tune buffer sizes and batching parameters for optimal performance.  I pretty much had to do that anyway, but it is now a little less obvious what my choices are.

     

    The bottom line for us is this: I have successfully built a prototype that covers all major aspects of our sync process (especially the things we need to do that our current implementation cannot do).  Based on this success, we plan to incorporate MSF 2.0 into our application.  MSF 2.0 is not a "perfect" solution, but its imperfections are managable.

     

    However, we still have some work to do, particularly in planning our development and testing efforts before we deploy this capability.  In particular, we are going to carefully plan our test effort and our client deployment.  Our test effort is going to attempt to identify high risk scenarios and then execute appropriate test cases to verify operations in those scenarios.   While we currently have a high degree of confidence in the framework, if it is going to fail we want it to fail as quickly as possible. 

     

    We also want to make sure that client deployment is as efficient and trouble-free as possible.  We have a lot of client systems and do not want to be in the situation of having to walk every single one of them through the upgrade process (we don't have to do that now with upgrades and we want this to be similar).  We also intend to operate the new MSF-based sync process in parallel with our original sync process for at least a little while (they have nothing in common).  That way, if there is some fatal flaw in our design or in the framework itself we are not stuck with a bunch of dead client applications and an angry user community while we are frantically trying to undo the disaster we just inflicted on them.

    Monday, April 12, 2010 5:26 PM
  • Would you be able to share your code. I am also researching WebSharingAppDemo and really need to be able to abstract it to sync over WCF. Please help!!
    Saturday, April 21, 2012 5:06 PM