Incremental deploy causes corrupted code (error A300000000)

Using 1.0.0 preview2, latest and greatest (20181003)

bootloader 2.0.4
firmware 1.0-2
libs 1.0-2
templates 1.0-2

Got this after very minor changes to a working project and even after removing that change it does not work. Restarting studio does not help. Simply reinstalling firmware does not help. Disconnecting/Connecting device does not help.

My feeling is that something goes wrong during deploy of assemblies (GHIElectronics.TinyCLR*) and that wrong is never detected by VS so it is never redeployed. Now this project is stuck with apparent dependency mismatch although there has only ever been one version on this board…

Another old project still works but creating a new project with same code and dependency does not

This was resolved by reinstalling firmware once again and doing a proper E(rase) this time. This forced all dependencies to be redeployed and everything works again.

How are programs stored on flash with tinyclrOS? It seems that several of my projects are loaded at once, do they share dependencies in that case?

It would be great if there could be a way to force redeployment of all assemblies (other than bumping into terraterm)

1 Like

It’s possible there were old cached assemblies still on the device. As you discovered a full erase can correct that (though you don’t need to do the firmware, simply erasing the deployment in TinyCLR Config is enough). We do plan additional tooling inside VS itself for a future release, along the lines of erase/save/create deployment.

1 Like

Nope as i mentioned there has only ever been the latest and greatest 1.0.0-2 on that device, so in this case that is not the problem. In this case i suspect some corruption that was not detected by incremental deploy.
In general though my feeling is that incremental deploy is somewhat broken. For example if you uppgrade firmware and libs without erasing you almost certainly wind up with this error. This is a problem form commercial applications since erasing the flash also erases personalisation.
Ideally deploy would correctly erase and redeploy all code that changed based on checksum or such…

I meant your own assemblies. It’s possible deploy didn’t work correctly and that there were old assemblies still on the device causing issues. We’ll certainly be looking into it.

I have gotten this a few times before.
I paused anti-virus (PC-Matic) rebuilt two or three times (must take pc-matic some time to pause everything) and it finally worked.