NeroCom NeroFileProducer

Okay, what’s the trick to getting the NeroCOM NeroFileProducer object to work properly? FYI, my app is written in C#.

When the OnProduceFile() event gets called, the Write method on the supplied NeroDataInputStream fails, terminating the thread that called the event. As a result, no data ever gets written.

The following fragment shows one of the alternatives I’ve tried, involving pinning the buffer I read/write to/from before calling the Write() method. The same failure also occurs if you just pass through the unpinned buffer.

My suspicion is that, despite the method template specifying that the first argument to Write() is an object, it actually has to be a particular kind of Nero object.

private void theProducer_OnProduceFile( ref int id, ref NeroDataInputStream pStream, ref NERO_ENTRY_ERROR pError )
{
FileStream curFS = File.OpenRead(fullPathToFile);

int bufSize = readBuffer.Length;
string fPath = thePR.FullPath;

ulong cumlBytes = 0;

// pin the buffer
GCHandle bufferHandle = GCHandle.Alloc(readBuffer, GCHandleType.Pinned);
IntPtr bufferAddr = bufferHandle.AddrOfPinnedObject();

while( cumlBytes < thePR.Bytes )
{
	int bytesRead = curFS.Read(readBuffer, 0, bufSize);

            // this next line FAILS, terminating the calling thread
	pStream.Write(bufferAddr, bytesRead);

            // so we never get here
	Debug.WriteLine(String.Format("Wrote {0} bytes from {1}", bytesRead, fPath));

	cumlBytes += (ulong) bytesRead;
}
bufferHandle.Free();
Debug.WriteLine("Produced " + thePR.FullPath);

curFS.Close();

pError = NERO_ENTRY_ERROR.NERO_ENTRY_NO_ERROR;

}

As noted several times recently, there are strange issues with COM to .NET interaction that cause an unexpected behavior when NeroCOM is used in .NET environment. A number of issues have been identified and a workaround has been found for them. They all seem to be caused by .NET’s COM Interop layer. You should expect all of these issues taken care of in the next update which should be released really soon now.

Alex,

Thanx for the quick reply. Any idea as to the specific timing of the next release?

Also, is there a workaround? For example, would it be possible to write a little managed C++ DLL that could properly handle the interface?

  • Mark

Sorry but I don’t have any dates.

As for the managed C++ DLL, I am not sure how that would help. The problem seems to be in the COM interop layer. Fortunately, there is a workaround for this .NET’s quirk.

Okay, thanx.

Do you know what the interop bug is in this case? Just curious.

  • Mark

Interop seems to fail to properly handle COM interface pointers introduced to the .NET environment through COM events.