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.
@ 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.
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.
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.
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.
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.
