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.
If an assembly needed updating :
Incrementally deploying assemblies to device
Deploying assemblies for a total size of 68232 bytes
If no assemblies were updated (no deployment ocurred) :
Incrementally deploying assemblies to device
All assemblies on the device are up to date. No assembly deployment was necessary.
@ 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.
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?
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.
I then decided to create a very simple project with nothing other than adding Glide and setting the backlight to on. Same damn error.
public class Program
static OutputPort LCDbacklight;
public static void Main()
LCDbacklight = new OutputPort(GHI.Pins.G400.PD3, true);
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.