Any plan of improving Visual Studio Extension?

TinyCLR OS
1

The TinyCLR Visual Studio extension seems to be quite fragile. After using it to deploy and debug about 15 or 20 times, the USB driver gets very, very buggy and I have to reboot.

Sometimes, only 5 or 6 deployments before I have to reboot. Sometimes it seems to work almost an hour before requiring a reboot. After rebooting it works just fine … for a short while.

Some of the many random symptoms …

  • Change my code, hit Start. Recompile, TinyCLR Deployment attempts to deploy the changes, but gives up and runs WITHOUT deploying the new code !
    Quite frustrating to be debugging and find out it’s running a previous version of code !

  • TinyCLR Deployment will die when trying to connect. Pops up the message “There were deployment errors. Continue?”. (At this point, TinyCLR Config can usually Connect/Disconnect just fine)

  • TinyCLR Deployment will only deploy some of the assemblies. Then when the debugger starts, it says that some assemblies are missing and quits.

For example:

Link failure: some assembly references cannot be resolved!!

Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Spi' (2.2.0.5000)
Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Gpio' (2.2.0.5000)
Assembly: GHIElectronics.TinyCLR.IO.TinyFileSystem (2.2.0.5000) needs assembly 'GHIElectronics.TinyCLR.Devices.Storage' (2.2.0.
5000)
Assembly: GHIElectronics.TinyCLR.Devices.Spi (2.2.0.5000) needs assembly 'GHIElectronics.TinyCLR.Devices.Gpio' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.IO.TinyFileSystem' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'AtlantisDevelopment.SDCardDriver' (1.0.0.0)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Storage' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Gpio' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Update' (2.2.0.5000)
Error: a3000000
Waiting for debug commands...

Try a few more times … and hoorah … it eventually will deploy all assemblies just fine.

  • TinyCLR Debugger will take a very, very long time to step over a simple line of code. Sometimes up to 30 seconds. But, hit F10 again and it immediately steps over the next line of code.

  • TinyCLR Debugger will hang at the end of the program. Normally, the debugger stops, but when then USB Driver is confused, the Debugger will just hang.

  • TinyCLR Debugger crashes Visual Studio. This is by far the most common symptom.
    Today, Visual Studio has crashed about 60 times. When Visual Studio restarts it states the “TinyCLR Extension has causes a crash” and suggests disabling it.

No other USB device has any problem at all. And … unplugging ALL USB devices except the PICO doesn’t really seem to make a difference at all. Still only works for a short while before needing to reboot again. No other problems with this PC or Visual Studio.

TinyCLR Config also has the same set of problems. It also starts working again without any problems upon rebooting … for a short while anyhow.

And … YES … I’m using a USB-A to USC-C cable directly plugged into the PC. Tried different cables. Shielded vs non shielded. Short vs long. tried different USB ports and connecting to a USB hub instead. No change.

Sometimes hitting RESET a couple times on the PICO seems to make things better for a couple deployments. But, rebooting is best.
Same symptoms happen with a Feather. Reboot and everything is fine for a while.

One other thing … it seems to work better on a slower PC. If the PC is fast, the TinyCLR Extension seems to die more quickly. My main development PC is 16 core (24 logical processor) i9-12900K @ 3.2 GHz running Windows 11 Pro 22H2 22621.1555. I haven’t tried it yet on an older very slow PC.
Visual Studio is Enterprise 2022 (64 bit) Version 17.5.4

So … any plan on improving the TinyCLR Visual Studio Extension?
Are there any logs I can send you that would help?
Or … is the source available so I can debug it myself?

Thanks !

My development of our TinyCLR embedded app is moving along nicely despite having to reboot constantly.

2

An update … disabling and reenabling the USB driver from Device Manager doesn’t seem to help.
But … uninstalling the SC13048 USB device DOES HELP.

Uninstalling the USB Driver and letting it reinstall itself is quicker than rebooting and seems to work.

It’s frustrating to debug when the TinyCLR Deployment doesn’t actually update the code on the PICO. It runs through the motions, but when the debugger starts … its still the previous version of code !

3

There is a setting to not run if the build fails.

image
image1115×651 84 KB

4

Changing that option would be great … except the Deployment DOES NOT fail.
TinyCLR Deployment THINKS the deployment has succeeded.

Deployment log …

Looking for a device on transport ‘USB’.
Found device port ‘USB’ with ID ‘c28fd0c2-0387-49f8-99d8-dacbaafb7435’ for transport ‘Usb’.
Starting device deployment.
Attempting to connect to device ‘USB:Syzydyne’: iteration 0.
Opening port ‘\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}’.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.

  • FOTA v1.0.0.0 with size 5,992 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\FOTA.pe’.
  • AtlantisDevelopment.SDCardDriver v1.0.0.0 with size 26,536 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\AtlantisDevelopment.SDCardDriver.pe’.
  • mscorlib v2.2.0.5000 with size 72,560 bytes at ‘E:\Projects\Mobile PC Manager\XXXX\XXXX\FOTA\bin\Debug\pe\mscorlib.pe’.
  • GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe’.
  • GHIElectronics.TinyCLR.Devices.Spi v2.2.0.5000 with size 6,284 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Spi.pe’.
  • GHIElectronics.TinyCLR.Devices.Storage v2.2.0.5000 with size 3,432 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Storage.pe’.
  • GHIElectronics.TinyCLR.IO v2.2.0.5000 with size 21,052 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\GHIElectronics.TinyCLR.IO.pe’.
  • GHIElectronics.TinyCLR.IO.TinyFileSystem v2.2.0.5000 with size 16,116 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\GHIElectronics.TinyCLR.IO.TinyFileSystem.pe’.
  • GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe’.
  • GHIElectronics.TinyCLR.Update v2.2.0.5000 with size 4,440 bytes at ‘E:\Projects\XXXX\XXXX\Mobile Devices\FOTA\bin\Debug\pe\GHIElectronics.TinyCLR.Update.pe’.
    Total deployment size is 167,492 bytes.
    Incrementally deploying assemblies to the device:
    Allocating assemblies:
  • Address: 0x08047000 => mscorlib
  • Address: 0x08058B70 => AtlantisDevelopment.SDCardDriver
  • Address: 0x0805F318 => GHIElectronics.TinyCLR.IO
  • Address: 0x08064554 => GHIElectronics.TinyCLR.IO.TinyFileSystem
  • Address: 0x08068448 => GHIElectronics.TinyCLR.Devices.Spi
  • Address: 0x08069CD4 => GHIElectronics.TinyCLR.Native
  • Address: 0x0806B50C => FOTA
  • Address: 0x0806CC74 => GHIElectronics.TinyCLR.Devices.Gpio
  • Address: 0x0806DF84 => GHIElectronics.TinyCLR.Update
  • Address: 0x0806F0DC => GHIElectronics.TinyCLR.Devices.Storage
    Deploying assemblies:
    Restarting interpreter.
    Attaching to device.
    Waiting for device to initialize.

Debug log …

Link failure: some assembly references cannot be resolved!!

Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Spi' (2.2.0.5000)
Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Gpio' (2.2.0.5000)
Assembly: GHIElectronics.TinyCLR.IO.TinyFileSystem (2.2.0.5000) needs assembly 'GHIElectronics.TinyCLR.Devices.Storage' (2.2.0.
5000)
Assembly: GHIElectronics.TinyCLR.Devices.Spi (2.2.0.5000) needs assembly 'GHIElectronics.TinyCLR.Devices.Gpio' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.IO.TinyFileSystem' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'AtlantisDevelopment.SDCardDriver' (1.0.0.0)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Storage' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Devices.Gpio' (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly 'GHIElectronics.TinyCLR.Update' (2.2.0.5000)
Error: a3000000
Waiting for debug commands...
5

I see your problem now. You need to update the assemblies used to build your code. Check your NUGET for the project and update all of them to 2.2.0.5000 or 2.2.0.5100 and try building again.

6

Dave,
Thanks for the Help !

From the NuGet Manager, it shows I am using the latest version of all GHIElectronics.TinyCLR.* packages. All of them are 2.2.0.5000

Which assemblies are you referring to ?

7

You might be missing some then. FOTA lists a number of them. Check your build has them included.

Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.IO.TinyFileSystem’ (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly ‘AtlantisDevelopment.SDCardDriver’ (1.0.0.0)
Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Storage’ (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Gpio’ (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Update’ (2.2.0.5000)

Save for the SD card.

Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Spi’ (2.2.0.5000)
Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Gpio’ (2.2.0.5000)
Assembly: GHIElectronics.TinyCLR.IO.TinyFileSystem (2.2.0.5000) needs assembly ‘GHIElectronics.TinyCLR.Devices.Storage’

8

Something to try… Use a powered USB hub between the PC and the device. Might help with the failure after a period of time.

1 Like
9

Dave,
That is the issue. Sometimes TinyCLR Deloyment will deploy the entire set of assemblies.
And then sometimes … it doesn’t deploy at all. But it thinks it deployed them.
When the Debugger runs, it says it cannot find the missing assemblies.

1 Like
10

Thanks Mike !
I’ll try that. I tried one from Amazon that was powered, but it didn’t make any difference. I’ll get a new one and try again.
Don

11

try erase all to see if that help.

12

Erase Application doesn’t make a difference.
Erase All doesn’t make a difference.

The problem is the Visual Studio Extension. It’s VERY buggy.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID '75aef62e-6324-4950-9da1-97127d128dc2' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:SC13048': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#7&2ac184dc&0&1#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

Found debugger!
Create TS.
Loading Deployment Assemblies.
Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
Ready.
Cannot find any entrypoint!
Done.
Waiting for debug commands...

At this point … TinyCLR Config says “No assembly found on device”.

13

Don

I am in the process of developing a program for a Flea. It drives a stepper motor for a watch winder. I have been happily compiling, loading and debugging without any issues.

There is something in your solution/project that is messed up…

First, have you tried building a new solution and adding your files to this solution? This has been known to help in the past.

If it is possible, you can send me your solution directory and I will take a look and see if I can get around the problem. No promises…

14

Did you add any reference? If so, check every reference to see if there is yellow exclamation mark.

16

Or if you can share the project to us to reproduce the issue.

17

Doesn’t seem to matter what application.

But, I figured out one of the issues. When I have a solution with multiple projects, the VS Extension can get confused. When I set the active application, the VS Extension keeps trying to deploy the previously selected application.

Looks like this has been a problem for many years.

Once the TinyVLR Visual Studio Extension thinks the assemblies are updated, it’s very hard to get it to deploy the correct set of assemblies.

If I had the source … I would find these FRUSTRATING bugs !

18

Dat Tran,
Here are a couple more issues I have found:

TinyCLR support for “foreach of a string”
With the following code anywhere in an application, Visual Studio gives an error message : CS7038 Failed to emit module ‘XXXXX.XXXX.XXXXX’: Unable to determine specific cause of the failure.
Took me a long time to find this one since Visual Studio doesn’t tell you where the problem is or give any hint…

string s = "some string";
foreach (char c in s)
{
	Function( c );
}

TinyCLR will cause Visual Studio to crash
Anytime an application being debugged runs out of heap, TinyCLR debugger locks up and Visual Studio crashes. Upon reload, Visual Studio recommends disabling TinyCLR Extension to prevent crashes.

This one is fairly easy to reproduce. Create a recursive loop, allocate too much memory, etc.

Haven’t been able to pinpoint the other issues. I’ll post them if I can get them cornered.

– Don

19

Dat Tran,

Here’s some more deployment logs that demonstrate one of the problems with TinyCLR Visual Studio Extension.

After erasing the Application using TinyCLR Config … I try to deploy and run an application.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
	- Writing sector 1 (2,048 bytes).
	- Writing sector 2 (2,048 bytes).
	- Writing sector 3 (2,048 bytes).
	- Writing sector 4 (2,048 bytes).
	- Writing sector 5 (2,048 bytes).
	- Writing sector 5 (2,048 bytes).
	- Writing sector 6 (2,048 bytes).
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

As you can see, the TinyCLR Visual Studio Extension ONLY wrote the first 6 sectors of the application! Where is the rest !!! … the VS Extension skipped them entirely.

The next time I attempt to deploy, it writes another 12 sectors. But, still not the entire application.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
	- Writing sector 7 (2,048 bytes).
	- Writing sector 8 (2,048 bytes).
	- Writing sector 9 (2,048 bytes).
	- Writing sector 10 (2,048 bytes).
	- Writing sector 11 (2,048 bytes).
	- Writing sector 12 (2,048 bytes).
	- Writing sector 13 (2,048 bytes).
	- Writing sector 14 (2,048 bytes).
	- Writing sector 15 (2,048 bytes).
	- Writing sector 16 (2,048 bytes).
	- Writing sector 17 (2,048 bytes).
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

Each time it deploys a little bit more, but never the entire application.
And each time, the Debug output has errors:

Found debugger!
Create TS.
Loading Deployment Assemblies.
Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
Ready.
Cannot find any entrypoint!
Done.
Waiting for debug commands...

And from then on … it thinks the application has been deployed. But it still hasn’t deployed the entire application. So … the debugger still cannot find an entry point.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

And now … the TinyCLR Visual Studio Extension is completely screwed. It WILL NOT deploy the application correctly.

So … now no matter what application I attempt to deploy. The VS Extension skips deployment entirely.

Here’s another log after I opened a new solution and attempt to debug it.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- MemoryTest v1.0.0.0 with size 848 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\MemoryTest\bin\Debug\pe\MemoryTest.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\MemoryTest\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\MemoryTest\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 79,608 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => GHIElectronics.TinyCLR.Native 
	- Address: 0x0805A3A8 => MemoryTest 
Deploying assemblies:
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

As you can see … it will not deploy that NEW application either. At this point the VS Extension is completely confused and will not deploy anything.

What else can I send you that will help you guys FIX the TinyCLR Visual Studio Extension ?
Thanks for your help !

– Don

20

Known issue. Been around a long time. Would be interesting to know why this is hard to fix.

I only see this issue once a project.

21

Another known problem.