Thanks for the output. You haven't give any idea of what version you were on previously but it always make sense to keep versions of mission critical software

Near the top of your output I think we see the real error

Library Include Paths (3)
Include Path 'C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\EEPROM\src'
Unable to resolve library include path 'spi'
Include Path 'C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire\src'
 

Can you please confirm the code you have used to #include the spi library?

EDIT: If upgrading from versions of Visual Micro from many months ago there is a new library-in-library discovery feature that is more accurate but less forgiving than the older system. However the new system is optional and can be disabled by un-checking "vMicro>Compiler>Deep Search Includes".

Thanks

Hi,

Quote:


If the software crashed and closed that shouldn't happen and vs shouldn't let it happen. Is that repeatable? So far you just posted an error not a crash report?

Versions

Which version of Visual Studio? Help>About?

Quote:


Explicit paths. Uggh. Arduino doesn't use explicit paths and that's difficult to test for or know what results you will get.

You haven't said what happens if you switch off "vMicro>Compiler>Deep Search" or were you aware of the feature and have coded for it. Adding library #includes to the project_name.ino negates most of what "deep search" is designed to do.

Quote:


Okay maybe this gives some clue as to the problem. This is an area that changed in the last release (see release notes)

Let;s be clear about what the _libraries folder is/was. The _libraries folder used to appear when you click "vMicro>Toggle Hidden Files". Clicking again removes the folder. The folder has been renamed to src\_micro-api-readonly\libraries.

Toggle hidden files gives "read only" shortcuts to the original source. These additions to a project are ignored by visual micro during compile because they are catered for during core and lib compilation. The hidden files are for display purposes only making it easier to reference them during project code creation.

You can click delete or right click "remove" these files which is the same as clicking the Toggle menu item again. I will do some more testing but it sounds like a bug related to hidden files is confusing the compiler library resolution. 

In the meantime I suggest you remove all library and and core short cuts from the project because they are easy to re-add, don't affect the source and will remove an element of confusion while we resolve the issue.

I have an explanation, if not a resolution.

There were bogus entries in the project file for non-existent copies of Spi.cpp and Spi.h.  They were non-existent because the 1.6.9 release of the Arduino support code moved them to a different place.   

Removing those entries allowed the build to complete.

This doesn't change the problem: VM did not handle a bad condition properly.  But thanks for the responses.  I hope I can go forward without needing to come back, so to speak.

Some suggestions: a lot of your text in various places, including the MSDN web page, is hard to read for anybody over 50.  Avoid gray text on white.  If you must use 8 pt text, as in Visual Micro Explorer, create an option to increase the size.  Thanks.

All I know is what I have told you.  The build output contained a .NET stack dump from a "bad instance of an object" exception.  It was highly reproducible: I backed out all my changes and repeated the build until I showed that removing those two bogus entries was the only thing needed to fix it.