I just ran over a nasty bug in StreamReader.
https://netmf.codeplex.com/workitem/2048
If a falls on a multiple of the internal buffer size you’ll get an IndexOutOfRangeException.
Hi there,
According the release notes MF4.2 , this issue has been solved…( do I interpretate the release notes correctly?). But I still run into this exception error - StreamReader.cs - IndexOutOfRangeException.
Info:
http://netmf.codeplex.com/workitem/1701
http://netmf.codeplex.com/wikipage?title=.NET%20MF%204.2%20Roadmap
How did you solve this problem?
Thanks, freeck
Actually I had this problem with 4.2 QFE2, so at least the problem I found out is not solved.
I assume that the bug is still in 4.3 QFE1.
In https://netmf.codeplex.com/workitem/2048 I added a comment that describes exactly where the exception occurs.
My solution was to not use the ReadLine method anymore for files larger than 512 bytes. I made a custom parsing method that did even parse the line itself as I needed it.
Another option would be that you copy the StreamReader class into your code with a different name, fix the bug there and use your own class then everywhere. I thought about that, but I was not in the mood of digging into the code to fix the bug.
Thanks for your quick response…I get realy frustated about .netmf , I spend and have spent more time debugging .netmf than develop my application until now.
Could you please send me the link of the source code of streamreader.cs?
Is it possible to “override” streamreader, thus not using another name?
Freeck
You can download the source code from codeplex or use a decompiler like ReSharper or Redgate Reflector.
It’s not possible to overwrite a class without giving it a different name.
You would need to build your own firmware, what is possible for GHI OpenSource HW but not for Premium Hardware.
About your frustration:
I tried Arduino and NETMF.
I know both C++ and C# quite well.
But the extremely limited debugging possibilities for Arduino makes me even more frustrated.
And working around bugs and issues is something I also have to do in Windows Applications (.NET and native).
If you don’t want to work around bugs from other people, you need to write the complete firmware on your own from scratch, which would be quite time consuming, and you might have more bugs than before.
But I agree that the bug fixing process on NETMF could be faster. 1st the NETMF team needs to fix it, then GHI needs to use the new NETMF Version, then they need to fix some bugs in their FW as well, …
But in fact I made some quite complex projects with GHI/NETMF devices already and I’m happy with it.
Ok, thanks for the mental support , I have to get used to bugs and live with it. I presume that embedded Linux also have flaws.
I use .netmf for the development of a smartmeter interface (monitor electricity and gas usage) , using the board as a datalogger and using a wifi-interface to communicate with the outside world. (Cerbuino Bee and wifly xbee module.), all seemed to work nicely until this bug appreared.
In the meantime I discovered this item:
https://www.ghielectronics.com/community/forum/topic?id=8577
Good to see. I think it’s time for a StreamReadEx class in my core library 8)