The size necessary to buffer the XML content exceeded the buffer quota
Anyone come across this error before? “The size necessary to buffer the XML content exceeded the buffer quota” Took me while to figure out, I got the error when running a report with in VS after making some changes, it didn’t seem to like me using a shared data set when setup as a procedure (even tho it was already setup prior). once I changed it to a Text script (i.e. Exec
Regards
ld Stoke-on-Trent
United Kingdom If at first you don’t succeed, go to the pub and drink away your current thought plan.
SSC Rookie Points: 43
July 20, 2017 at 2:24 am #1951794 Edit | Close | Stick (to front) | Merge | Trash | Spam | Reply —>
Viewing 2 posts — 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSCRM Package Deployer error: The size necessary to buffer the XML content exceeded the buffer quota. #191
Buddy3000 opened this issue Feb 1, 2019 · 5 comments
MSCRM Package Deployer error: The size necessary to buffer the XML content exceeded the buffer quota. #191
Buddy3000 opened this issue Feb 1, 2019 · 5 comments
Comments
Buddy3000 commented Feb 1, 2019
I am attempting to deploy a solution to Dynamics 365 from an Azure DevOps pipeline using MSCRM Package Deployer. It used to work, but now always fails. Attached is an extract from the pipeline log.
The important part of the log is:
PackageDeployer Error: 2 : Message: WASolution — Importing solution threw and unforeseen exception
Source : mscorlib
Method : HandleReturnMessage
Error : The size necessary to buffer the XML content exceeded the buffer quota.
Stack trace and other information can be viewed in the attachment.
The text was updated successfully, but these errors were encountered:
WaelHamze closed this as completed Feb 3, 2019
charliechen179 commented Jul 29, 2019
@WaelHamze @Buddy3000 I’m having the same issue right now. I tried to run the package deployer on my local machine, but I get the same error message. Do you have any clue? Thanks.
Microsoft.Xrm.Tooling.Connector.CrmServiceClient Verbose 16 7/29/2019 12:21:01 Failed to Execute Command — ImportSolution : RequestID=3d44c33c-05b5-4cbe-be3e-d77f7d3d39ca : duration=00:00:16.9776490
Microsoft.Xrm.Tooling.Connector.CrmServiceClient Error 2 7/29/2019 12:21:01 ************ Exception — ImportSolution : Executing ImportSolutionRequest for ImportSolutionToCrm |=> The size necessary to buffer the XML content exceeded the buffer quota.
Source : mscorlib
Method : HandleReturnMessage
Date : 7/29/2019
Time : 12:21:01
Error : The size necessary to buffer the XML content exceeded the buffer quota.
Stack Trace : Server stack trace:
at System.Runtime.BufferedOutputStream.WriteCore(Byte[] buffer, Int32 offset, Int32 size)
at System.Runtime.BufferedOutputStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Xml.XmlBinaryNodeWriter.FlushBuffer()
at System.Xml.XmlStreamNodeWriter.UnsafeWriteUTF8Chars(Char* chars, Int32 charCount)
at System.Xml.XmlBinaryNodeWriter.UnsafeWriteText(Char* chars, Int32 charCount)
at System.Xml.XmlBinaryNodeWriter.WriteText(Char[] chars, Int32 offset, Int32 count)
at System.Xml.XmlBinaryNodeWriter.WriteEscapedText(Char[] chars, Int32 offset, Int32 count)
at System.Xml.XmlBaseWriter.WriteChars(Char[] chars, Int32 offset, Int32 count)
at System.Xml.XmlBinaryWriter.WriteTextNode(XmlDictionaryReader reader, Boolean attribute)
at System.Xml.XmlDictionaryWriter.WriteNode(XmlDictionaryReader reader, Boolean defattr)
at System.ServiceModel.Channels.ReceivedFault.CreateFault11(XmlDictionaryReader reader, Int32 maxBufferSize)
at System.ServiceModel.Channels.MessageFault.CreateFault(Message message, Int32 maxBufferSize)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.Xrm.Sdk.IOrganizationService.Execute(OrganizationRequest request)
at Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient.<>c__DisplayClass40_0.b__0()
at Microsoft.Xrm.Sdk.WebServiceClient.WebProxyClient 1.ExecuteAction[TResult](Func 1 action)
at Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient.ExecuteCore(OrganizationRequest request)
at Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient.Execute(OrganizationRequest request)
at Microsoft.Xrm.Tooling.Connector.CrmServiceClient.CrmCommand_Execute(OrganizationRequest req, String `errorStringCheck)«`
charliechen179 commented Jul 29, 2019
@WaelHamze @Buddy3000 I think my issue is mainly because I deployed a new managed solution having dependencies in unmanaged solution.
Buddy3000 commented Jul 30, 2019
This was 6 months ago so forgive my mind being a bit hazy. I solved a few problems back then, and I cannot remember which solution solved which problem, but I think the solution below is the correct one for this problem. If not then please reply and I’ll rack my brain some more.
If you crack open the solution zip file you will find a data.xml file within. Opening this file, you should see a line like this at the top:
The problem arises because of the timestamp value, and I think it is a locale issue. When I extracted the zip, I extracted using my local machine with a UK locale. But on upload, I used an Azure DevOps agent that was running on a US locale. And so it threw a wobbly because 15/01/2019 is not a valid US date (for the US the equivalent date would be written 01/15/2019).
Fortunately, the file will upload just as happily if you strip out this timestamp. I.e. replace the line above with this and all is good and should work:
So I fixed this with a little PowerShell, that unzipped the file, removed the timestamp attribute, and then zipped it all back up again.
The key lines of PowerShell that I wrote for this are:
Expand-Archive -LiteralPath $zipfile -DestinationPath $tempDirectory -Force
[xml]$data = Get-Content -Path $dataFile
$data.entities.Attributes.RemoveNamedItem(«timestamp»)
$data.Save($dataFile)
Compress-Archive -Path $tempDirectory\* -DestinationPath $zipfile -Force
Hope that helps? Let me know how you get on.
SSRS error on preview : «The size necessary to buffer the XML content exceeded the buffer quota» hides original error
I understand that there is definitely something wrong with my report (e.g. columns missmatcch) and I need to correct it but what I see is the WCF error message that hides actual problem and exactly this hiding irritates me much more than original problem: columns missmatch. I guess we need to adjust the WCF ‘buffer size’ and we will get original problem message. But where is the config file? Text search of «system.serviceModel» in the C:\Program Files (x86)\Microsoft Visual Studio 10.0 doesn’t bring good idea. P.S. Since this is just preview of report I do not think that it is SSRS configuration problem. Problem localised somewhere in DevStudio process or int the DevStudio’s internal web server process . P.P.S Please help me too improve the question. I see that responders doesn’t understand what kind of help I need.
- visual-studio-2010
- wcf
- reporting-services
- sql-server-data-tools
- ssrs-2012
9,845 145 145 gold badges 482 482 silver badges 880 880 bronze badges
asked Apr 23, 2014 at 8:50
Roman Pokrovskij Roman Pokrovskij
9,637 21 21 gold badges 92 92 silver badges 146 146 bronze badges
I think there is a problem with your .rdl file. This issue is usually solved by debugging changes made to your report. Did you copy and paste a report created in an older version to a newer version of markup?
Apr 24, 2014 at 2:22
@lrb , there are two problems — one is error in my report, second is the problem with configuration of VS inernals (the internal wcf client can’t get actual error message from internal web server because the message is too big). With the help of community I want to try to solve second one.
Apr 24, 2014 at 6:53
Hi, I think the error about buffer size is coming from ssrs and being properly returned via your wcf service. Your wcf service is returning the error properly from ssrs. You would get a Channel error or something if the buffer size was configured too small in your wcf service.
Apr 24, 2014 at 12:50
That makes sense. I should test is ssrs really used for preview. So, I have disabled ssrs service: the same message; all other reports preview works. I still think that VS launch internal web server.
Apr 24, 2014 at 12:59
Roman Pokrovskij — The «xml buffer size» is a red herring. The error returned via the WCF service was an error returned from its own call to SSRS. The WCF service conveyed the correct error back to the client, however, the «xml buffer size» is an SSRS error, not a WCF service binding error. What makes this even more confusing is that SSRS’s «xml buffer size» error is in itself a red-heron and not the true cause of the error in the .rdl processing.
SOLVED: “The size necessary to buffer the XML content exceeded the buffer quota” (SSRS)
OMG…I hate this one.
Most of the times when you’re using textbox references (like: ‘Reportitems!Textbox33.Value‘) and when I think you press ‘Delete’ on certain cells, VS automatically renews the textbox-numbers. So things get messed up.
So…check if any of your report items are referencing non-existing textbox items, non-existing paramters or fields that are not in existing dataset scope.
Funny thing is that when you start deleting other report items (of which you think they work properly), VS somehow makes up his mind by giving you a decent error message: