Cannot find any entrypoint!

I am porting a 4.2 application to 4.3 and it builds and deploys but I get the following error when it runs

I do have main declared of course and the only changes were to remove and add the correct GHI references.

Any ideas what I am missing as I have never had this issue before when porting to 4.3


Cannot find any entrypoint!

Done.

Waiting for debug commands...

'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\mscorlib.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Native.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Security.PKCS11.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.Security.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Graphics.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.TinyCore.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.Usb.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.SerialPort.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Touch.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Ink.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.PWM.dll', Symbols loaded.
The program '[0x5] Micro Framework application: Managed' has exited with code 0 (0x0).

I should add that this is a G400 and a test programme works.

This is what appears when it deploys:


... debugger engine attached!
Querying device assemblies...
Found Assembly mscorlib 4.3.1.0
Found Assembly Microsoft.SPOT.Native 4.3.1.0
Found Assembly Microsoft.SPOT.Security.PKCS11 4.3.1.0
Found Assembly System.Security 4.3.1.0
Found Assembly Microsoft.SPOT.Hardware 4.3.1.0
Found Assembly Microsoft.SPOT.Graphics 4.3.1.0
Found Assembly Microsoft.SPOT.TinyCore 4.3.1.0
Found Assembly Microsoft.SPOT.IO 4.3.1.0
Found Assembly System.IO 4.3.1.0
Found Assembly Microsoft.SPOT.Hardware.Usb 4.3.1.0
Found Assembly Microsoft.SPOT.Hardware.SerialPort 4.3.1.0
Found Assembly Microsoft.SPOT.Touch 4.3.1.0
Found Assembly Microsoft.SPOT.Ink 4.3.1.0
Found Assembly Microsoft.SPOT.Hardware.PWM 4.3.1.0
Found Assembly G400Test 1.0.0.0
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Net.pe to deployment bundle
Adding pe file C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.3 SDK\Libraries\le\ghi.hardware.pe to deployment bundle
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Net.Security.pe to deployment bundle
Adding pe file C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.3 SDK\Libraries\le\ghi.glide.pe to deployment bundle
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.Http.pe to deployment bundle
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.Xml.pe to deployment bundle
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.pe to deployment bundle
[b]Adding pe file C:\Users\Dave McLaughlin\Documents\Visual Studio 2013\Projects\TankLevelGHI400\TankLevelGlide\bin\Debug\le\TankLevelGlide.pe to deployment bundle[/b]
Adding pe file C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.3 SDK\Libraries\le\ghi.pins.pe to deployment bundle
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.Xml.Legacy.pe to deployment bundle
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.Net.Security.pe to deployment bundle
Adding pe file C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.3 SDK\Libraries\le\ghi.networking.pe to deployment bundle
Attempting deployment...
Incrementally deploying assemblies to device

The line 25 shows that it deployed.

The first posting shows what appears after it exits.

Doing some more digging.

If I add any GHI reference to my test solution it gives me the error when it starts.

If I remove the reference and the debug, it gives me the error. If I do a clean and the debug it runs. Adding any GHI reference gives the can’t find entry point error.

This is all being done with VS2013 so I about to test with VS2012

One thing that I discovered yesterday is that if I modify the references in my sln in VS2013, I sometimes need to exit and restart VS2013 before the build works again correctly. I have no idea why, but clearly there is some caching going on. Building clean did not help - only exit and restart and then magically my deploy would work. I repro’d this three separate times yesterday.

In my case the symptom was a simple ‘deploy failed’ with no explanation in the output window.

I should note that I am very close to the line with regards to the size of my flash image, and got similarly strange results (deploy or launch failures with no clear cause) when I went over that limit. Could the swapping of ref’s have pushed you over the available flash storage?

I’m definitely not the most experienced one here, but these are my experiences from just yesterday when refactoring references in VS2013.

I think what you said is true. I did a clean, exited VS and then re-started it and then it worked.

It could well be related to the change from 4.2 to 4.3 and the new references. Either way, it works now and I will try this the next time the same thing happens.

My test programme was created during the same running so it may be related. That now works too since the restart.

Andre, sometimes (many times ?), it is not enough. You really have to restart VS2013.
Either you cannot deploy or if deploy is successful, then execution cannot find entry point.

It happens more often when you are near the limits, indeed, but even with very small programs it tends to happen after many deployments as well.

Tried that a few times and didn’t make any difference.

The exit and restart mcalsyn mentioned was the only fix for it.

PS… I don’t see anywhere now that shows you the code size that will be loaded to the device. I am sure it used to show you this when it built and started the deploy.

If an assembly needed updating :
Attempting deployment…
Incrementally deploying assemblies to device
Deploying assemblies for a total size of 68232 bytes

If no assemblies were updated (no deployment ocurred) :
Attempting deployment…
Incrementally deploying assemblies to device
All assemblies on the device are up to date. No assembly deployment was necessary.

Damn. I saw it this time but it keeps getting cleared once the Found Debugger message appears. Wish it would just keep scrolling the window instead of clearing it.

It was about 800K in my case.

@ Dave McLaughlin - It shouldn’t be clearing it - it is just in another output stream. There is a dropdown box marked “Show output from” in your output window in VS. Select “Micro Framework Device Deployment” for deployment messages. “Debug” for runtime messages.

What you are seeing as clearing is really just VS switching windows.

2 Likes

There may be different reasons for this error message, I don’t know. I was definitely able to reproduce it with my GSIoT book samples on Mountaineer boards and on Netduinos. Our current theory is that if a solution becomes non-trivial in some unknown sense, the whole build mechanism begins to break down. In order to keep some sanity, we try to organize our sources in a way that makes dealing with multiple versions of NETMF and multiple hardware target platforms reasonably simple. This has resulted in quite a number of projects within a single solution.

This in turn seems to result in frequent build or deploy problems, leading to several near-mutinies in our company (“NETMF is a f*ing toy, why haven’t we switched to another platform”). Sometimes all references must be completely reconstructed by hand to make things work again (for a while, until for no visible reason things again stop working), this cost us several days of work during our integration of PolarSSL into the Limmat firmware.

One theory is that building a project within a solution may overwrite files belonging to another project that has already built. In this simple case, simply trying to deploy again works. But there may be other causes for this error message.

In our view, after the networking problems have been addressed in V 4.4, this kind of problems is the single most important issue to be addressed in order to turn NETMF into a trustworthy platform.

Interestingly, though, it has to be coupled to something in-memory with VS2013. It can’t be just a filesystem problem. Either something about the reference set is kept in memory (unlikely), or something about the reference set or assembly manifest is being cached on disk and not invalidated when the ref set changes. Restarting VS must cause VS to rebuild that cache or lose track of the original corrupt cache and the manifest is correct again with respect to the reference set.

Because of the pain it causes, I’m going to start tracking deployment manifests and the dll and file refs with procexp when it happens (before and after restart) and try to figure out what’s being held onto. Then maybe I can file a coherent bug against this little ‘feature’.

For me, it doesn’t seem to matter how big or complex the soln is - I can repro it with changes in the reference set of a dependent (classlib) assembly.

DOH!! You really can teach old dog new tricks!

Cheers mcalsyn… :slight_smile:

*&%$%##&%@ &@

:wall:

I updated to the latest pre-release and again I am getting this “cannot find entrypoint!” error and I tried the same things I did last time but nothing is working.

The total deploy is 802220 bytes so well within the 1.4MB available on the G400.

After my R3 and Win10 update, I ran into problems too and needed to unplug/replug the usb cable and switch the deploy target from USB to Serial to USB again to get VS to fix up it’s internal state and deploy correctly. I can’t say that’s the same as what you’re seeing, but it fixed it for me. I have also recently seen a repeat of the case where new code did not actually get deployed and the board ran old code.

In all these cases, a reboot and/or switching the deployment target fixed it up.

If that doesn’t do it, can you share your deployment and debug logs?

I decided to create a new project and import the files to it but now run into another issue. I have a bunch of images in the resources but the code now gives me this error


Error	9	'TankLevelG400LCD5.Resources' does not contain a definition for 'GetBitmap'

for this and any other line where I make this call.


gprsState.Bitmap = Resources.GetBitmap(Resources.BitmapResources.state0);

For some reason it does not load them into the correct type. :frowning:

How did you move the resources over? What tab do they show up on when you click on Resources.resx? Also, expand Resources.Designer.cs in the solution explorer and open the Resources.Designer.cs file and see what VS generated in there. That will tell you what names the code generator gave to your resources.

@ Dave McLaughlin - Save your project before importing the bitmaps and then again then i think they will magically work.

$%^*

The brand new build still doesn’t work. Same damn error.

WTF!!! :wall:

I then decided to create a very simple project with nothing other than adding Glide and setting the backlight to on. Same damn error.


using System;
using Microsoft.SPOT;
using System.Threading;
using GHI.Pins;
using Microsoft.SPOT.Hardware;

namespace TestG400
{
    public class Program
    {
        static OutputPort LCDbacklight;

        public static void Main()
        {
            LCDbacklight = new OutputPort(GHI.Pins.G400.PD3, true);

            while(true)
            {
                Thread.Sleep(1000);
            }
        }
    }
}

If I then run this in the emulator, I see the loading and a crash on the LCDbacklight call which is to be expected so this is something to do with the G400 module. I am going to try and reflash it.

Yes, this is often needed. Probably some caching consistency problem in VS. Known for ages, hard to explain to novices why it should be necessary, and never addressed by Microsoft.

Do you know whether there is a GitHub issue for that problem? Maybe the new team is not aware of this kind of problem.