Hi all. I am finally getting to updating a large solution from preview 5 to 2.0.0. I am having an issue building. If I create an entirely new solution, I can build and deploy and everything runs, so I am confident I have the correct firmware and vsix installed. However, my legacy solution from preview 5 just will not deploy (although it builds just fine). It comes back with this error:
The assembly ‘mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ has been referenced multiple times with different versions.
The assembly ‘mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ cannot be found.
This is very strange because the Core nuget is definitely in the packages directory in the solution and if I load the mscorlib.dll assembly in PowerShell to check the PublicKeyToken, they match. I also went through each project file in the solution and made sure there were no lingering references. I have cleaned the solution, tried uninstalling all nuget packages and reinstalling… Basically everything I can think of. I cant find any reference to anything other than the 2.0 packages. Any ideas? I really don’t want to have to remake the entire solution as it is quite large.
Many internal changes happened in the visx that it will be a good idea to start a new project and at all your files. I understand this is time consuming but you may end up spending more time trying to figure out what is wrong.
I kinda figured that was going to be the answer, but was hoping it wasn’t! In some good news, I did get my little network test running with some threads and it looks like you guys were correct in saying the thread blocking issue for ethernet is fixed. Hopefully the entire solution runs once I get it remade.
So it looks like I have 2 issues happening with ethernet.
1.) It looks like NetworkStream.Read is returning 0 bytes read when it hits the timeout. It should return an IOException when this happens. See: NetworkStream.ReadTimeout Property (System.Net.Sockets) | Microsoft Learn
It should only return 0 when it gets a FIN from the other side. In this case, there is no way to know if it timed out or if the connection is in the process of tearing down.
2.) I will work on a test app for this one to share, but it looks like somehow after each time Socket.Accept accepts a new connection, a thread running a UART hangs till the ns.Read() times out. I can see the data going out on the line and coming back, but debug.WriteLine statements placed throughout the UART code hang up after the send until I get the thread exit message from the thread running the ns.Read(), then execution resumes. Its especially odd because after I send the line on the UART, I immediately do a read. There is nothing between the two, so the thread is definitely being blocked. Also, if I send in 2 commands via tcp/ip back to back, the second will “unstick” the first and the UART code proceeds normally from the point it hangs up, likely because the ns.read is returning after reading the second message. Then, the second message will stick in the same spot till the timeout. Certainly seems like there is still a thread blocking issue with TCP/IP and the UART. Oh, and the initialization code for the box uses many UART commands, all of which work properly, so this only happens once the ethernet accepts a connection. I am on the 2.0 libraries, so could upgrade to 2.1 and test if you believe there might be a difference. Also, what UART devices do you have? My code is specific to a syringe pump, so not sure how I can build you a test app.