Error in Custom Pipeline Component for BizTalk 2004
Matthew Roche
In an attempt to add a unique identifier to incoming flat files (for additional context information, see "Accessing the BizTalk Message ID in a Map" in biztalk.nonxml) I have created a new Custom Pipeline Component based on the FxMsg sample component in the updated BizTalk 2004 SDK. Basically I have taken the sample, changed the class and namespace names and updated the IComponent Execute() method to use the following code instead of using the AppendData and PrependData properties:
byte[] prependByteData = ConvertToBytes(inmsg.MessageID.ToString() + ",");
The good news is that I have been able to develop, debug and deploy the pipeline component with relatively little pain. The bad news (of course) is that it doesn't work. When I build a receive pipeline that uses my AddGuid component in the decode stage and submit a file to the receive location, I get the following errors in Event Viewer:
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5719
Date: 6/27/2004
Time: 8:34:51 AM
User: N/A
Description:
There was a failure executing the receive pipeline: "BTS_SendPortScript_Test.BTSR_ScriptFFReceive" Source: "Microsoft.BizTalk.Pipeline" Receive Location: "C:\Projects\BTS_TestingProject\BTSR_Receive\*.000" Reason: Index was outside the bounds of the array.
This error is immediately followed by these:
The "FILE" adapter is suspending a message coming from Source URL:"C:\Projects\BTS_TestingProject\BTSR_Receive\*.000". Details:"The Messaging Engine encountered an error during the processing of one or more inbound messages. ".
The Messaging Engine has suspended "1" message(s) from adapter "FILE" due to failures in message processing. Please refer to Health and Activity Tracking tool for more detailed information on this failure.
As far as I can tell there is nothing related to these messages at all in the H&A Monitor, but I'm honestly not too comfortable with that tool anyway.
For additional information, what the component does is to turn the first line of an inbound flat file from this:
20040616,"002476",757
to this:
5d9c715b-df6e-46c3-83c5-59a2a33439b4,20040616,"002476",757
By adding some debug code to my pipeline component I have been able to verify that this is working properly. If I put this line immediately preceding the return statement in Execute()
System.Diagnostics.Debug.WriteLine(new StreamReader(strm).ReadToEnd());
the text sent to the Output window in Visual Studio is exactly what I want to see, and when copied and pasted into a text file validates successfully against the text file schema used by the flat file disassembler in the Disassemble stage of the pipeline. (Yes, I have this line commented out in my code - when it is not commented out I get a "There was a failure executing the receive pipeline: "BTS_SendPortScript_Test.BTSR_ScriptFFReceive" Source: "Flat file disassembler" Receive Location: "C:\Projects\BTS_TestingProject\BTSR_Receive\*.000" Reason: None of the components at Disassemble stage can recognize the data. " error, I assume because I've already read to the end of the stream and there's nothing left to disassemble.)
I need to solve this error so that I can successfully use this pipeline component in my project. If anyone can share their wisdom and assistance, it would be greatly appreciated.
Matthew
Matthew Roche
First, assuming that the error must be mine, and that I changed something in the FixMsg sample inappropriately, I tool these steps:
* I compiled and installed the FixMsg sample and used the component in the decode stage of my receive pipeline
* I set the "prepend data" property of the component to "5d9c715b-df6e-46c3-83c5-59a2a33439b4," (without the quotes, of course) to simulate what I want my component to add to the beginning of received files
* I submitted a text file and received this error:
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5719
Date: 6/27/2004
Time: 6:16:07 PM
User: N/A
Computer: OMITTED
Description:
There was a failure executing the receive pipeline: "BTS_SendPortScript_Test.BTSR_ScriptFFReceive" Source: "Microsoft.BizTalk.Pipeline" Receive Location: "C:\Projects\BTS_TestingProject\BTSR_Receive\*.000" Reason: Index was outside the bounds of the array.
So, I'm getting the same error using literal inputs to the unmodified sample component from the BizTalk 2004 SDK.
Next, while examining the sample BizTalk project in the SDK in which the FixMsg component is used, I noticed that the component is being used in the Validate stage with no disassembler being used in the pipeline, where I am using it in the Decode stage with the Flat File disassembler in the pipeline. It is my understanding that the Flat File disassembler is responsible for parsing inbound flat files into the internal XML representation that BizTalk uses, so it seems logical to me that I need to insert my data into the file stream before it gets disassembled. Still, in the context of testing, I updated the receive pipeline to use the FixMsg component in the Validate stage, and got this error:
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5719
Date: 6/27/2004
Time: 6:30:15 PM
User: N/A
Computer: OMITTED
Description:
There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: "C:\Projects\BTS_TestingProject\BTSR_Receive\*.000" Reason: None of the components at Disassemble stage can recognize the data.
This makes sense to me, because the file I submitted did not include the GUID field that the Flat File disassembler (or more specifically, the schema with which the FFD is configured) is expecting. In this test configuration (using the FixMsg component in the validate stage) I submitted a text file with the GUID field manually added, and it was successfully disassembled and (I assume) "validated" by FixMsg, because I got this error:
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5782
Date: 6/27/2004
Time: 6:32:47 PM
User: N/A
Computer: OMITTED
Description:
The Messaging Engine failed while executing the outbound map for the message going to the destination URL "SQL://(local)/taco/" with the Message Type "http://TACOProject.TACOSchema#Root". Details:"The data at the root level is invalid. Line 1, position 1."
So, I can only conclude that the FixMsg component and the programming approach that it used cannot be used at the decode stage in a receive pipeline. What do I need to do differently to add a GUID value to the beginning of an incoming flat file *before* it gets disassembled? Thanks in advance!
Matthew
Gilles [MSFT]
[...]
>There was a failure executing the receive pipeline: "BTS_SendPortScript_Test.BTSR_ScriptFFReceive" Source: "Microsoft.BizTalk.Pipeline"
>Receive Location: "C:\Projects\BTS_TestingProject\BTSR_Receive\*.000" Reason: Index was outside the bounds of the array.
Your custom pipeline component seems to be throwing an exception when it runs. Somewhere, in your code, you seem to be using
an index that is out of the bounds of an array.
Reading your investigations, it does not appear obvious to me that you debugged the code when it is running. I suggest you debug your
code with Visual Studio .NET 2003 and break on first chance CLR exceptions. This will brak right at the point where the execption is being
thrown and you will be able to go down the stack and understand the issue.
Here is how to do this.
1) Rebuild your custom pipeline solution. Copy the dll to <bts setup root>\Pipeline Components (with the pdbs).
2) Shut down the Biztalk host that runs this custom pipeline and restart it. This is needed because the CLR cannot
unload an assembly. It needs to unload the whole application domain. So if you rebuild your component, the new
one will not be used until you shutdown the host and restart it
3) Attach VS.NET to BTSNTSvc.exe and select CLR debugging.
4) (Enable first change exceptions on CLR) In VS.NET, select Debug->Exceptions..."
5) In the dialog, select "Common Language Runtime Exceptions". Do *not* expand it,just select it by clicking on the word "Common".
6) At the bottom of the dialog, there is a "When Exception is thrown" section. Select "Break Into the debugger" and click OK.
Now, send a message that triggers your pipeline. You will see exceptions being thrown. Be careful, some will be "normal"
exceptions that are totally expected. Continue (pressing F5) until you get "index is outside the bounds" exceptions. Break on that one,
bring the call stack window. You will most likely be somewhere in the runtime code. Look down the stack and find the frame in your code.
It is possible that you will see [Non User Code"] in the stack trace when you break. If this happens, right click anywhere inside the call
stack window and select "Show non user code".
Thanks.
-Gilles.
Matthew Roche
You are correct - the FixMsg pipeline code is throwing this exception on this line of code:
bytesRead = stm.Read(buffer, offset, count);
This is line 213 in the FixMsgStream.cs file included with the BizTalk SDK.
Is it possible to receive assistance with this sample code, or now that we've identified the source of the error do I need to resolve it myself?
Matthew
Gilles [MSFT]
>You are correct - the FixMsg pipeline code is throwing this exception on this line of code:
>bytesRead = stm.Read(buffer, offset, count);
Good! We have a starting point for further investigations.
>This is line 213 in the FixMsgStream.cs file included with the BizTalk SDK.
>Is it possible to receive assistance with this sample code, or now that we've identified the source of the error do I need to resolve it myself?
If I remember properly, your goal in this custom disassembler pipeline component is to replace the following:
(assumed to be at the beginning of the stream)
20040616,"002476",757
to this:
5d9c715b-df6e-46c3-83c5-59a2a33439b4,20040616,"002476",757
I understand (and please correct me if I am wrong) that you have modified the sample code. Unfortunately, modified sample code
is considered "customer code" and as such, most likelty, Microsoft support would probably charge you if you opened an official
assistance request.
However, you seem to have made only a few changes to the sample and your issue seems very scoped and reproducible 100%.
Also, you might have uncovered an issue in the sample. So in your specific case, if you post the following:
1) complete list of modifications you made to the sample so I can apply those changes on my system
2) A typical message that your component is supposed to act on
and I'll reproduce it and suggest potential fixe(s) for free but you can always open a service request :-)
I cannot promise I'll tackle this immediately after you post, but I'll definitely get back to you.
Thanks.
-Gilles.
Matthew Roche
Although I do encounter this exception with my modified version of the FixMsg sample code, I have also reproduced it with the unmodified code directly from the SDK as part of my troubleshooting. If I need to open an "official" support incident that's fine (one of the many joys of having an MSDN Universal subscription ;-] ) as long as I can get the problem solved. Here's what information I have to share:
* My requirements are to add a GUID, followed by a comma, to the beginning of incoming flat files. This will provide the inbound files with a unique identifier that they do not have natively so that I can track duplicate file submission. Ideally the GUID will be the BizTalk MessageID, but this is not truly necessary.
* Because I received this exception after using my modified copy of the FixMsg sample code, I tried using the unmodified sample, passing in a string containing a GUID and a comma, and receive the same exception.
* To reproduce the error, configure a receive pipeline with the FixMsg component in the Decode stage - configured with the text "f48e47e8-32ed-4a66-90b2-086938391db7," (without the quotes) as its PrependData value - and the Flat File Disassembler at the Disassemble stage.
* To reduce the manual steps you'll have to take, I've also shared the following files at ftp://biztalk.kicks-ass.net/bts/ForGilles.zip. You should feel free to ignore the "send" components and just dump any output to the file system - as long as we can get the pipeline component working I'll be delighted - but I wanted to be as complete as possible.
+ All files in my test project - schemas, maps, pipeline and so on
+ The SQL Server stored procedure code to which the inbound messages are mapped
+ The SQL Server tables used by the stored procedures
Everything should be pretty much self-explanitory - I am not, to the best of my knowledge, doing anything fancy or complicated. The one thing that is somewhat unusual is the file extension for input files - you'll have to configure your receive location to poll for *.000, and not *.TXT.
Thanks again for your assistance!
Matthew
Gilles [MSFT]
Just one thing. Did you update your BizTalk SDK, documentation and Binaries with the April release? The SDK was enhanced
so it might be that you had a problem with it. On this page: http://www.microsoft.com/biztalk/downloads/versions/default_2004.asp
you want to install the "Rollup Package", the Product documentation update, the SDK refresh. If you wish to use the enhanced tutorials,
you can also install them from the "Tutorials" links. I suspect you did update, but just to be sure. I do not believe this update was
actually merged with the MSDN subscription, but I can be wrong.
Anyway, I dowloaded the file and I could not find the source of the custom decode component so I used the sample to write one.
I re-guided the sample FixMsg, made it a decode stage only, removed the unneeded properties and also removed all the code that
appends data. I created a receive pipeline with this component at decode stage
(do not forget to copy the component's dll to <btsroot>\Pipeline Components) and I ran it using pipeline.exe. I got:
8a793b93-cafd-42a5-831d-88bdf9184d2b,20040616,"002476",757
"002476",20040616,"AL1",1,102.17
[ ... the remaining of your sample text file here ...]
So this seems to be doing the job. For those who do not know about pipeline.exe, look at the middle of this page
http://msdn.microsoft.com/library/en-us/sdk/htm/ebiz_sdk_utils_pipeline_ackm.asp?frame=true
Since I did not do anything besides removing the append related code, it should have worked for you as well.
I am not sure exactly what happened. What matters is that now, you are unblocked.
I zipped my solution and put it at http://www.winisp.net/frenchgilles/Prepend.zip
I have not attempted to play with maps and/or SQL stored procedures. Let's handle one problem at a time ;-)
Hope this helps.
Thanks.
-Gilles.
Matthew Roche
Yes, I updated the SDK with the April release, although I have not installed the "Rollup Package."
I deliberately did not include my pipeline component code in the Zip file I shared, since it is "customer code" and I receive the same error using the SDK's FixMsg code. I assumed that we could work with the the SDK code and that I could take it from there. I have not used the Pipeline.exe utility - I'll have to take a look.
I will download your code and see how it works. Thanks so much for your assistance!
Matthew
Matthew Roche
I've installed and tested your component, and receive the same error. I can only assume that the problem is something related to my development system, so I will address that and let you know when I have it resolved. Thank you very much for all of your assistance and debugging tips!
Matthew
Gilles [MSFT]
>Yes, I updated the SDK with the April release, although I have not installed the "Rollup Package."
I suggest you apply the rollup package. This page give the list of fixed issues:
http://support.microsoft.com/default.aspx?scid=kb;en-us;837168
>[...] I have not used the Pipeline.exe utility - I'll have to take a look.
Ah, forgot to mention that the tool itself can be found inside <Installation Path>\SDK\Utilities\PipelineTools.
It makes testing pipelines so much faster that everyone should know about it.
That seems like a great topic to blog about ...
Feel free to post here if the pipeline does not work as expected.
Thanks.
-Gilles.
Gilles [MSFT]
>I've installed and tested your component, and receive the same error. I can only assume that the problem is something related to my
>development system, so I will address that and let you know when I have it resolved. Thank you very much for all of your assistance and
>debugging tips!
Did you use pipeline.exe to test ? Anything special (i.e. that you have not yet talked about here) in the even tviewer?
Thanks.
-Gilles.
Matthew Roche
The error I received is from using a "real" BizTalk receive pipeline, and not Pipeline.exe. I have a simplified test project, and have written a small C# utility that makes "un-hooking" an assembly before undeployment, and "re-hooking" an assembly after deployment much quicker. Because of this, it seemed more logical to test against BizTalk itself instead of learning a new command-line utility.
In the context of the event viewer, each time I submit a document to the receive location that uses the receive pipeline with this custom component, these three entries are added to the Application log:
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5719
Date: 6/30/2004
Time: 7:51:52 PM
User: N/A
Computer: OMITTED
Description:
There was a failure executing the receive pipeline: "BTS_SendPortScript_Test.BTSR_ScriptFFReceive" Source: "Microsoft.BizTalk.Pipeline" Receive Location: "C:\Projects\BTS_TestingProject\BTSR_Receive\*.000" Reason: Index was outside the bounds of the array.
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5753
Date: 6/30/2004
Time: 7:51:52 PM
User: N/A
Computer: OMITTED
Description:
The "FILE" adapter is suspending a message coming from Source URL:"C:\Projects\BTS_TestingProject\BTSR_Receive\*.000". Details:"The Messaging Engine encountered an error during the processing of one or more inbound messages. ".
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5752
Date: 6/30/2004
Time: 7:51:53 PM
User: N/A
Computer: OMITTED
Description:
The Messaging Engine has suspended "1" message(s) from adapter "FILE" due to failures in message processing. Please refer to Health and Activity Tracking tool for more detailed information on this failure.
The only other BizTalk-related messages are from my stopping and starting the service for testing, and there are no error (or warning) messages in the System log that appear even vaguely related to me.
Just to keep you informed, I have installed the "rollup package" and the error still occurs. I have performed a "repair" installation of BizTalk (followed by a reapplication of the rollup package) and the error still occurs. My next step will be to reinstall the .NET Framework (the error is occuring in C# code, so who knows - it may not be BizTalk specific...) and then reinstall BizTalk Server if that is not successful. Hopefully nothing more than that will be necessary...
Matthew
Matthew Roche
I have even more evidence that this error is due to some problem or corruption specific to my development machine. I'd moved this morning to work on the ASP.NET front end that will (eventually) display the data being loaded through BizTalk server, and started getting the same "Index was outside the bounds of the array" error in a line of code (DataTable.Select()) that has not changed in three months or more; this error is also not reproducable on any other machines...
So, since reinstalling BizTalk and the .NET framework did not do the trick, it's time to reinstall Windows XP and start from scratch. It's going to be a long weekend...
Matthew
Gilles [MSFT]
>I have even more evidence that this error is due to some problem or corruption specific to my development machine. I'd moved this morning to
>work on the ASP.NET front end that will (eventually) display the data being loaded through BizTalk server, and started getting the same "Index
>was outside the bounds of the array" error in a line of code (DataTable.Select()) that has not changed in three months or more; this error is also
>not reproducable on any other machines...
It seems that your .NET framework has some problems. Just a question: did by any chance setup any of the Microsoft Visual Studio
codename "Whidbey" on the machine which shows the issue? There were known issues w/ side by side execution with pre-beta 1 versions.
Also, currently, some features of BizTalk 2004 do not work if you have a version 2.0 of the CLR installed.
If that was the case, you would need to uninstall the said version of Visual Studio as well as the Framework 2.0 and re-map ASP.NET to be 1.1.
>So, since reinstalling BizTalk and the .NET framework did not do the trick, it's time to reinstall Windows XP and start from scratch. It's going to
>be a long weekend...
Ah ... hopefully, this fixes the problem. Let us know if there are anymore BizTalk related problems.
Thanks.
-Gilles
Matthew Roche
No - I have not installed any version of Whidbey (or Yukon, for that matter ;-]) on this computer. I have a dedicated suite of virtual machines that I use for testing pre-release software - I'm pretty careful about letting things like that touch a production machine.
I've got Windows XP reinstalled and am working on getting SQL Server, Visual Studio and BizTalk Server installed and configured. Once this is done I'll install and test the custom pipeline component and will let you know (crossing fingers here) that it all works beautifully...
Matthew
Matthew Roche
The bad news is that after completely wiping out my development workstation and reinstalling from scratch Windows and all of my tools, this "Index was outside the bounds of the array" error is still occurring.
The good news is that I have eliminated the other similar error that I reported in my ASP.NET code. Although the ASP.NET code had not changed, one of my team members had changed the data with which it worked, and because of the ill timing I assumed that it was a related error, and not an unfortunate coincidence.
In short, this error is still reproducible with the modified FixMsg pipeline component that you sent to me, with the unmodified FixMsg pipeline component from the (recently-reinstalled) updated BizTalk 2004 SDK, and with the AddGuid pipeline component that I have created my modifying the FixMsg sample. Because this error occurs after a complete system reinstallation, I can only assume that this is an issue with BizTalk and not with my development workstation.
Here are steps to reproduce this error:
* Compile and deploy the FixMsg custom pipeline component from the April 2004 refresh of the BizTalk SDK. You will need to place a key file named FixMsg.snk in C:\Program Files\Microsoft BizTalk Server 2004\sdk\Samples\Pipelines\CustomComponent\FixMsg before compiling. Copy the DLL and PDB files from \bin\debug to the C:\Program Files\Microsoft BizTalk Server 2004\Pipeline Components folder. (Please note that I have selected the SDK FixMsg component deliberately to avoid any issues of this error being related to modifications to the code.)
* Using Visual Studio.NET, create a new Empty BizTalk project
* Add to the project the two schemas and one map file found in ftp://biztalk.kicks-ass.net/bts/biztalk_error_repro.zip
* Add a strong name key file to the project
* Add a new receive pipeline to the project, configuring it with the FixMsg component at the Decode stage and the flat file disassembler at the Disassemble stage
* Set the Prepend Data property of the FixMsg component in the receive pipeline to "EC69AFE5-E486-4436-B8F4-782F6997ADD3," without the quotes.
* Set the Document Schema property of the Flat File Disassembler in the receive pipeline to ScriptTest.xsd.
* Build and deploy the BizTalk Server project
* Create a new receive port
* Create a new receive location in the new receive port that uses the File transport and polls the file system for *.000 and uses the receive pipeline created above
* Create a new send port that uses the File transport to save XML files, uses the default XMLTransmit send pipeline, has a filter property to accept messages from the receive port created above, and uses the BTSR_to_AH1 map from the BizTalk Server project as its outbound map
* Connect the Visual Studio debugger (loaded with the FixMsg SDK code) to BTSNTSvc.exe following your earlier instructions
* Place a breakpoint on line 196 of FixMsgStream.cs, just within the Read() method
* Submit Error_Repro_Test_Input_File.000 to the receive location
* When Read() is executed by BizTalk Server (I assume that this is the [<Non-user Code>] in question, Read() will see that prependData is not null, execute the block beginning on line 201 and then, when reaching line 213, throw the System.IndexOutOfRangeException. When attempting to execute stm.Read(buffer, offset, count), buffer's Length is 10, offset equals 10 and count equals zero.
At this point I am stumped. My experience working with streams in .NET is minimal, and I've lost a week on this problem already. Can you please reproduce the error at your end? I've taken (and documented) these steps to attempt to ensure that there is not some crucial step that I'm missing, or some heinous mis-step that I am making, and I cannot find anything of the sort. The only thing that I can think of is that the FixMsg code was not designed to work with the 37-length prependData array we're providing and that it's attempting to read from the stream when in fact it should only be reading from the prependData array at this point. This doesn't explain why this would work for you using Pipeline.exe, but without a working example (or better knowledge of this type of code) I can't hope to fix it alone.
Hopefully I've provided enough information for you to work with. Thanks again for all of your help!
Matthew
Matthew Roche
Just to let you know, I've opened a PSS incident for this problem. You've been very responsive and helpful, but I've become the bottleneck for the project and I need to get this resolved ASAP, and getting directly in touch with the support team (and cutting out the delay inherent in these forums) seems like my best bet. I don't know what your relationship is with the BizTalk PSS folks (or if you're one of them) but I'll be sure to mention to them how helpful you've been. Thanks again!
Gilles [MSFT]
[...]
Sorry about the ill timing. The good news that I was able to reproduce this behavior with your explanations. I cannot at the moment comment
further on this: I have not yet investigated but I wanted to get back to you as soon as possible to let you know that I am looking into this.
I'll get back to you as soon as I have some clarity on this.
Thanks.
-Gilles.
Matthew Roche
Thanks for the heads-up. I've just received confirmation from the BizTalk support guy working on my case that he is also able to reproduce it. At least I'm not going crazy...
Matthew
Gilles [MSFT]
[...]
So after reproducing, I received the error message:
There was a failure executing the receive pipeline: "Repro.ReceivePipeline" Source: "Microsoft.BizTalk.Pipeline" Receive Location: "<some
path>\*.000" Reason: Index was outside the bounds of the array.
Now, I understand exactly what happens. The SDK sample FixMsg contains a custom .NET stream implementation
(in file FixMsgStream.cs). This implementation does not properly handle all cases and you encoutered one of them.
In your specific scenario, the "Read" function first receives an order to read 10 bytes from the beginning of the stream
and the prepend data is of 37 bytes, so the first read does not actually consume all data.
As a result, the code at line 209 sets count to 0. Line 213 executes and call Stream.Read with a count = 0.
The implementation of IStream on msg (line 213) throws the aforementionned exception, causing the pipeline to fail.
As I am sure you are aware, the pipeline infrastructure calls Read() with a buffer already allocated (you cannot change it),
an offset in that buffer as well as count. The implementation of Read() must handle all requests appropriately (i.e. it is not
because the buffer you received was to short that you can go and enlarge it, you have to honor the request).
The size of the buffer is determined by the pipeline infrastructure and cannot be predicted.
No one knows before hand how large count will be and no one should assume any size. It is likely (while this have not been
confirmed yet) that on my system, the size of the buffer passed was larger than yours, which hides the corner case.
In your very specific case, one way of fixing this is to change the Read() function of my previous "Prepend" disassembler to be:
override public int Read(byte[] buffer, int offset, int count)
{
int ret = 0;
int bytesRead = 0;
// Do we have data to prepend?
if (prependData != null)
{
// Compute how much prepend data is left to send
int availablePrependData = prependData.Length - prependDataOffset;
bytesRead = count > availablePrependData ? availablePrependData : count;
Array.Copy(prependData, prependDataOffset, buffer, offset, bytesRead);
prependDataOffset += bytesRead;
offset += bytesRead;
count -= bytesRead;
ret += bytesRead;
// Did we consume all prepend data?
if (prependDataOffset >= prependData.Length)
prependData = null;
}
// Do we need to put more data in the buffer to satisfy this read?
if (count > 0)
{
bytesRead = stm.Read(buffer, offset, count);
ret += bytesRead;
}
return ret;
}
Note that this code is to get you unblocked on your project (and hopefully, I got it right). It is provided "AS IS" ...
I strongly suggest you review it and stress test it and ensure that it performs as expected. I ran your message
throught it and it produced an XML so this should at least get you going.
Matthew, I understand that you are already in contact with a Microsoft support professional. We are currently investigating this further.
Please accept my sincere apologizes for not finding this issue faster.
Thanks.
-Gilles.
[[ I speak for myself, opinions here are mine, not necessarily the one of my employer ]]
Matthew Roche
Thank you!!
I've implemented your updated code and it looks great. I have not performed any real testing, but my initial "smoke test" was successful, and that is very promising. I've got several thousand documents that I can use for testing this weekend, so hopefully everything will be cool. Have a great weekend!
Matthew