Posting this for anyone else running into the same problems I have coming right out of the mailer and onto my test bench.
TLDR; If you get confusing errors when trying to push a program to the device, try a different USB port, or try plugging into one that is on a 4-port USB hub. I suspect the Visual Studio Plugin has some USB device enumeration problems.
Full disclosure: I’m a crusty old semi-retired product engineer with a focus on prototypes. I still tinker and love new toys.
TinyCLR - FEZ Duino - Visual Studio setup:
First off, there doesn’t appear to be a step-by-step “Out of the box” tutorial to get you up and running. If there is one, I missed it. I respectfully suggest adding one along with the kinds of typical (and maybe some not-so-typical) problems new folks might encounter. Like yours truly.
Here’s the steps I took and the problems I ran into, along with the happy-ending we all look forward to. 
Note that simply plugging in the unit with a USB-C results in the blinky-light app running on the unit. I’m going to assume that the app was loaded prior to shipment as a way to verify that it’s working. This is a good indicator that your device is functional when you pull it from the static-laden mailing envelope.
Also, at this point, if you try to upload a sample or test program through Visual Studio before flashing the device, you’ll get errors. Lots of them.
Step one:
With Visual Studio 2022 installed with the appropriate TinyCLR plug-in module loaded and your USB-C cable plugged into the unit and your PC, follow the GHI documentation to download and install the TinyCLR Config tool and flash the device with new Firmware.
A couple things here:
-
When you download anything from GHI’s site, you’ll need to use something other than Brave browser as it just eats whatever error you encounter trying to download. It doesn’t display any notices that something’s wrong. I started up M$ Edge browser and caught that the GHI download can’t be performed securely, so you must manually intervene in order to keep any of the files.
-
You may notice that (at least on the FEZ Duino) there’s no informative silk-screen telling you what ‘core’ your device uses. The CPU is simply stamped with the STM CPU part number and has no ‘core’ emblem or ID. You have to go to a separate site to find out what that is. In my case, the main web site tells me that my FEZ Duino uses the SC20100S ‘core.’ (Suggestion: Lots of room on the underside of this board guys, how about silk-screening the ‘core’ identifier on there as well?)
So before you visit the firmware download page, visit GHI’s main site page to look up the table that matches Marketing name of your board with the engineering descriptor.
Step Two:
When you first run TinyCLR Config it’ll likely throw its first error:
“Device’s version mismatch. Some features may work incorrectly.”
Just continue - you can ignore this error.
Next, start up the TinyCLR Config tool, then click on the ellipses (…) to the left of the Update Firmware button and locate the updated firmware you downloaded in Step One for your specific ‘core’ device. Once you see the file is queued up, click the Update Firmware button and click ‘Yes’ in the are-you-sure-you’re-sure you want to erase the firmware dialog box.
A green progress bar should show up while it flashes the board. If successful, you’ll get a status of: Upload complete. Please reconnect.
So, you’ve downloaded the newest firmware for your device and it successfully installed. Now you’re ready to install your first test application and run it, right? Well, maybe. But in my case, no such luck.
Having successfully loaded and compiled the TinyCLR blinky-light test app, I press F5 and in the debugger window I get:
Looking for a device on trasnport ‘USB’.
Found device port ‘USB’ with ID
Starting device deployment.
Then. ERROR.
A pop-up from Microsoft Visual Studio politely suggests:
“There were deployment errors. Continue?” (Yes or NO?)
Clicking ‘NO’ results in another most-helpful debug output of:
'An error has occurred: please check your hardware."
So now, if you open up your TinyCLR Config tool and select Reboot (something I learned being a M$ alumni) you might see something in the Debug window that looks like:
???{T
?-Found debugger!
Create TS.
Loading Deployment Assemblies.
Attaching deployed file.
Assembly: mscorlib (2.0.0.0)
Error: the reference mscorlib cannot be used with this version of the firmware.
Firmware checksum 0x8FF20F1B does not match the assembly checksum 0x7A386EAC.
Resolving.
Ready.
Cannot find any entrypoint!
Done.
Waiting for debug commands…
Note that if you attempt to copy-paste this text, you’ll only get the first 8 or so characters, because embedded into the string at the beginning are some bytes and a few control characters - at least one of which is a null termination byte - thus preventing typical copy/paste unless you select starting at “Found…”
(Suggestion: please look at your code that updates the Windows textbox control - or rich textbox control, because it’s getting spammed with binary data.)
Well, there’s some useful information here, but as it turns out, it’s bogus. It claims there’s a mismatch in versions, but since we’ve only followed directions and used the genuine GHI firmware, this shouldn’t really happen, right? Good assumption! Now you’re thinking like a true engineer!
So you do this process a couple more times, but you find that if you click ‘YES’ in the Visual Studio dialog box instead of NO, you’ll get a much more informative error message looking something like:
An exception occurred while attempting to launch the debugger:
Cannot open
\?\usb#vid_1b9f&pid_5010#6&35844985&0&2#{ big old GUID goes here}
You may recognize that string as a registry key for a USB device - giving us Vendor ID = 1B9F and a Product ID = 5010. A quick perusal of the publicly available USB database comes up with nothing, which is disappointing.
However, I did notice that the GUID shown in this new error doesn’t match the GUID found in the earlier Visual Studio error.
Once you acknowledge this somewhat more informative error, another less-informative one takes its place from Microsoft Visual Studio. Just click OK on the “Unspecified error” dialog box.
So, having done the go-around with M$ and USB devices on more than a few occasions in the past, I decided to try a different USB port on my PC and moved the plug. Instead of using the dedicated USB 3.0 port, I used a slave port from a 4-port USB 3.0 Hub on my bench and wouldn’t you know it? It worked the first pass with almost lightning speed.
The could be’s:
It could be that there’s something weird going on with my dedicated USB 3.0 port, but this is highly unlikely as the 4-port HUB that I eventually plugged the cable into is actually plugged into the sister USB 3.0 port on the PC. (sister-port means that it’s on the same internal hub, just different port.)
It could be that Visual Studio or the TinyCLR plug in that is performing USB device enumerations is having some issues. I wouldn’t be surprised if this is indeed the cause, because in my own experience writing code for M$ USB devices for several products in the past, it’s always been quite tricky compared to doing similar things in Linux.
Well, good luck and happy coding! I hope this helps some other newcomers along the way.
-Mike