Search Results

Search found 3 results on 1 pages for 'daleykd'.

Page 1/1 | 1 

  • The maximum message size quota for incoming messages (65536) has been exceeded.

    - by DaleyKD
    My WCF Service has an OperationContract that accepts, as a parameter, an array of objects. This can potentially be quite large. After looking for fixes for Bad Request: 400, I found the real reason: the maximum message size. I know this question has been asked before in MANY places. I've tried what everyone says: "Increase the sizes in the client and server config files." I have. It still doesn't work. My Service's web.config: <system.serviceModel> <services> <service name="myService"> <endpoint name="myEndpoint" address="" binding="basicHttpBinding" bindingConfiguration="myBinding" contract="Meisel.WCF.PDFDocs.IPDFDocsService" /> </service> </services> <bindings> <basicHttpBinding> <binding name="myBinding" closeTimeout="00:11:00" openTimeout="00:11:00" receiveTimeout="00:15:00" sendTimeout="00:15:00" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647" transferMode="Buffered" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"> <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" /> <security mode="None" /> </binding> </basicHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior> <serviceMetadata httpGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="true" /> <dataContractSerializer maxItemsInObjectGraph="2147483647" /> </behavior> </serviceBehaviors> </behaviors> <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> </system.serviceModel> My Client's app.config: <system.serviceModel> <bindings> <basicHttpBinding> <binding name="BasicHttpBinding_IPDFDocsService" closeTimeout="00:11:00" openTimeout="00:11:00" receiveTimeout="00:10:00" sendTimeout="00:11:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true"> <readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" /> <security mode="None"> <transport clientCredentialType="None" proxyCredentialType="None" realm="" /> <message clientCredentialType="UserName" algorithmSuite="Default" /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="http://localhost:8451/PDFDocsService.svc" behaviorConfiguration="MoreItemsInObjectGraph" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IPDFDocsService" contract="PDFDocsService.IPDFDocsService" name="BasicHttpBinding_IPDFDocsService" /> </client> <behaviors> <endpointBehaviors> <behavior name="MoreItemsInObjectGraph"> <dataContractSerializer maxItemsInObjectGraph="2147483647" /> </behavior> </endpointBehaviors> </behaviors> </system.serviceModel> What can I possibly be missing or doing wrong? It's as though the service is ignoring what I typed in the maxReceivedBufferSize. Thanks in advance, Kyle UPDATE Here are two other StackOverflow questions where they never received an answer, either: http://stackoverflow.com/questions/2880623/maxreceivedmessagesize-adjusted-but-still-getting-the-quotaexceedexception-with http://stackoverflow.com/questions/2569715/wcf-maxreceivedmessagesize-property-not-taking

    Read the article

  • Why does the proxy generated code create the wrong class namespace when a MessageContract is in my W

    - by DaleyKD
    I have created two WCF Services (Shipping & PDFGenerator). They both, along with my ClientApp, share an assembly named Kyle.Common.Contracts. Within this assembly, I have three classes: namespace Kyle.Common.Contracts { [MessageContract] public class PDFResponse { [MessageHeader] public string fileName { get; set; } [MessageBodyMember] public System.IO.Stream fileStream { get; set; } } [MessageContract] public class PDFRequest { [MessageHeader] public Enums.PDFDocumentNameEnum docType { get; set; } [MessageHeader] public int? pk { get; set; } [MessageHeader] public string[] emailAddress { get; set; } [MessageBodyMember] public Kyle.Common.Contracts.TrackItResult[] trackItResults { get; set; } } [DataContract(Name = "TrackResult", Namespace = "http://kyle")] public class TrackResult { [DataMember] public int SeqNum { get; set; } [DataMember] public int ShipmentID { get; set; } [DataMember] public string StoreNum { get; set; } } } My PDFGenerator ServiceContract looks like: namespace Kyle.WCF.PDFDocs { [ServiceContract(Namespace="http://kyle")] public interface IPDFDocsService { [OperationContract] PDFResponse GeneratePDF(PDFRequest request); [OperationContract] void GeneratePDFAsync(Kyle.Common.Contracts.Enums.PDFDocumentNameEnum docType, int? pk, string[] emailAddress); [OperationContract] Kyle.Common.Contracts.TrackResult[] Test(); } } If I comment out the GeneratePDF stub, the proxy generated by VS2010 realizes that Test returns an array of Kyle.Common.Contracts.TrackResult. However, if I leave GeneratePDF there, the proxy refuses to use Kyle.Common.Contracts.TrackResult, and instead creates a new class, ClientApp.PDFDocServices.TrackResult, and uses that as the return type of Test. Is there a way to force the proxy generator to use Kyle.Common.Contracts.TrackResult whenever I use a MessageContract? Perhaps there's a better method for using a Stream and File Name as return types? I just don't want to have to create a Copy method to copy from ClientApp.PDFDocServices.TrackResult to Kyle.Common.Contracts.TrackResult, since they should be the exact same class. Thanks in advance, Kyle

    Read the article

  • Why does the proxy generated code create a new class when a MessageContract is in my WCF Service?

    - by DaleyKD
    I have created two WCF Services (Shipping & PDFGenerator). They both, along with my ClientApp, share an assembly named Kyle.Common.Contracts. Within this assembly, I have three classes: namespace Kyle.Common.Contracts { [MessageContract] public class PDFResponse { [MessageHeader] public string fileName { get; set; } [MessageBodyMember] public System.IO.Stream fileStream { get; set; } } [MessageContract] public class PDFRequest { [MessageHeader] public Enums.PDFDocumentNameEnum docType { get; set; } [MessageHeader] public int? pk { get; set; } [MessageHeader] public string[] emailAddress { get; set; } [MessageBodyMember] public Kyle.Common.Contracts.TrackItResult[] trackItResults { get; set; } } [DataContract(Name = "TrackResult", Namespace = "http://kyle")] public class TrackResult { [DataMember] public int SeqNum { get; set; } [DataMember] public int ShipmentID { get; set; } [DataMember] public string StoreNum { get; set; } } } My PDFGenerator ServiceContract looks like: namespace Kyle.WCF.PDFDocs { [ServiceContract(Namespace="http://kyle")] public interface IPDFDocsService { [OperationContract] PDFResponse GeneratePDF(PDFRequest request); [OperationContract] void GeneratePDFAsync(Kyle.Common.Contracts.Enums.PDFDocumentNameEnum docType, int? pk, string[] emailAddress); [OperationContract] Kyle.Common.Contracts.TrackResult[] Test(); } } If I comment out the GeneratePDF stub, the proxy generated by VS2010 realizes that Test returns an array of Kyle.Common.Contracts.TrackResult. However, if I leave GeneratePDF there, the proxy refuses to use Kyle.Common.Contracts.TrackResult, and instead creates a new class, ClientApp.PDFDocServices.TrackResult, and uses that as the return type of Test. Is there a way to force the proxy generator to use Kyle.Common.Contracts.TrackResult whenever I use a MessageContract? Perhaps there's a better method for using a Stream and File Name as return types? I just don't want to have to create a Copy method to copy from ClientApp.PDFDocServices.TrackResult to Kyle.Common.Contracts.TrackResult, since they should be the exact same class. Thanks in advance, Kyle

    Read the article

1