Deployment issue using Fez Panda III and tinyClr 0.7

hi everybody
I try to deploy my solution on my board Panda III (G80), each time I get the same message…

Looking for a device on transport 'USB'.
Found device port 'USB' with ID '9d438d8a-ff58-49f7-8695-683f333dfe7e' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:G80': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5009#6&38d1a08a&0&4#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Querying device assemblies.
Found assemblies:
The assembly 'TinyCLRApplication2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' cannot be loaded.

I remember having the same issue with 0.6 version. I try another USB port while the one I used was USB3. But USB2 is same result.

Any idea of this issue ?

Thanks

Does it happen if you create a brand new application without changing any of the code?

Yes brand new. I tried 3 or 4 different project each time new.

I tried the first time Tinyclr with the 0.6 version, and this error of deployment message came. I decided to wait the next version, thinking it could be due to the firmware. But actually, it does the same with the 0.7.

I tried to flash the firmware with the tool TinyCLR config and with serial console. But it seems that both way the firmware is ok on the board.

Visual studio see the board with no problem. I think the nuget packages are well installed too since there are no errors in code…

here is the test code

    using System;
    using System.Collections;
    using System.Text;
    using System.Threading;

using GHIElectronics.TinyCLR.Devices.Gpio;


namespace TinyCLRApplication2
{
    class Program
    {
        static void Main()
        {
            GpioPin led = GpioController.GetDefault().OpenPin(
            GHIElectronics.TinyCLR.Pins.FEZPandaIII.GpioPin.Led1);
            led.SetDriveMode(GpioPinDriveMode.Output);

            while (true)
            {
                led.Write(GpioPinValue.High);
                Thread.Sleep(100);
                led.Write(GpioPinValue.Low);
                Thread.Sleep(100);
            }
        }
    }
}

So, I don’t know where to look to find the reason.

Any chance you can try the same board and same setup on a different PC?

I tried with a laptop.
I install the same way than for the desktop for VS, but didn’t install local nuget lib.
VS open correctly the project, and I had chance to deploy it correctly on my fez panda III. All is normal.
So, problem could be linked to nuget installation ?

So the question now is what is wrong on desktop ?
I managed to uninstal VS2017, and re-intsall it, but no changes.

Is my way to install nuget lib is correct ?
USB ports not compatible with deployment ? (but it works well with tinyCLR Config)

I f you have got an idea…I take it with great pleasure ! So I can test tinyCLR on desktop for my future dev :slight_smile:

Have you tried other USB ports on the desktop? How did you install the NuGet packages? All that should be required is creating a local feed.

After lots of experiments, I found the problem…

I noticed that creating a project on my laptop, and open it with my desktop was ok…and very strange…
It means that the problem is during the creation of the project…
I make lots of tests and finally I can say that the problem is the location of the project.

On my laptop, the location is C:, on my desktop, my location is on an another disk.
While I didn’t notice this type of problem with plain NETMF and Gadgeteer, it seems that with tinyCLR it doesn’t work.
Could be it due to the NuGet loading ? (when you click to install each packages device, pins, etc…)

So, now, I have to work on my C: to make it working properly.

1 Like

Hard to say without being able to reproduce it here. What are the exact paths of everything in your project so we can try to recreate it here

I was writing down the results of my multi project creation in different cases of paths(30 perhaps )
But I find the final problem…

The path for the solution contains a folder called “C#”…
It seems that # is really not welcome…
I changed the “C#” into “C sharp”, and all is ok…

Can you confirm it with your conditions ?

I was able to reproduce the issue here but there is no fix at this time.

No problem with the fix for me since I know now the source of the problem. Renaming a folder is not hard job to do. But it’s good for you to know for future, or issue that could be created by same source. TinyCLR is great project, so I can’t wait for next versions :slight_smile:

This has been fixed for the next release