Visual Studio and many other IDEs have a configuration file for the current project, that's independent of the machine it's running on, usually with references to what files are part of the project and etc. AND another configuration file that is bound to the current machine, usually with the path to SDKs on the hard drive (like the Arduino files on this case).

The advantage of this (A HUGE ADVANTAGE BTW) is collaboration. You can add your project to Git and share all your code and project, but keep the machine bound configurations files on the .gitignore file, so no one will suffer with these being shared back and forth.

Currently Visual Micro gives me headaches with it's single configuration file. I work on two computers, each have a different file structure and Serial Port numbers and when I clone the Visual Micro project it brings all the other computer's information with it.

It would be a lot better if there was like in Visual Studio, a .suo to be ignored and a .sln to be kept.

Hi,

Thanks for the post.


Quote:

bound to the current machine, usually with the path to SDKs on the hard drive (like the Arduino files on this case).

I am confused about what you are asking to be separate?

The arduino ide location is not saved into the project.
The core and include paths are automatically discovered when a project is opened.

What exactly is causing you a problem?

The

On the vcxproj file there are some tags holding references to my machine's filesystem:

<AdditionalIncludeDirectories>

<ForcedIncludeFiles>

<ProjectExtensions>
    <VisualStudio>

If you want I can send you my vcxproj by email for you so you can check the references I am talking about.

Hi,

These settings purely relate to intellisense and Visual Micro remakes them when projects are opened or board changed, libraries added, code saved etc.

We use the currently configured ide and board to remake these properties. They are never read back for compilation. In theory we are similar to the arduino ide that doesn't have a project file.

Maybe there are other properties that you are finding to be a problem?

Does this make sense?

It does makes sense, but the problem is, every time I pull some change I made on my other PC I have to reconfigure the Serial Port number, and then the vcxproj file changes and git will see it and mark it as changed, which is VERY annoying.

E.g. on my laptop I have Serial Port 4 and on my desktop is Serial Port 13, so I change some code on my desktop, commit it, push, and pull it on my laptop later (remember this is just me on 2 different machines, but it could be 2 different people working on the same project). So now my laptop will have a reference to Serial Port 13, if I run Visual Micro I will get an error trying to find the Arduino on Port 13, so I have to change it back to Serial Port 4, and when I do it, vcxproj is changed again, git shows it as a changed file and everything starts all over again.

Okay makes sense. Trying to avoid reading a 2nd file when moving between projects. The vccproj is in memory so it's quick to read and save.

How about an option to switch off saving project port. Visual micro already saves the last port to the registry so that could be used. It would mean that you only have one retained port per machine.  All projects will use the last selected port.

Any good?

I don't think this will be enough. The <AdditionalIncludeDirectories> and <ForcedIncludeFiles> keep changing as well since in my laptop I use C:\ and in my desktop it is M:\.

Besides as I move the file back and forth some information gets left there, I can see folder structures from my desktop on my laptop .vcxproj file, this garbage information although it might not matter for Visual Micro functionality, it surely doesn't look much clean.

I shall try to experiment but the VS project/intellisense properties you mention are located where Microsoft have designed them to be located. Maybe relative paths will help? Do you have similar file structure for location of arduino core and libraries?

No I don't have similar paths for Arduino core files and libraries.

My laptop has one SSD, so just C:\ drive, but my desktop has two drives, an SSD in C:\ and a ,large HDD on M:\

I never had any issues with Visual Studio running C# projects. I place the .suo on .gitignore (among other user specific VS files, if you want a complete list I can give it to you) and let all the people I contribute with have the .sln on source control.

Hi,

I would like to find a better solution for you but it would be useful to first get a clear understanding of what needs to happen and why.

Having the same structure for relative paths excludes the drive: from the path so does not mean the disk drive mappings have to be the same. It would mean that if the project is under mydocuments and the arduino ide a level or two above and in some sub folder the paths would work on both machines. For example, assume the project is the start of the relative chain.

..\..\programs\arduinoide_folder
..\mydocuments\arduino\libraries

.. in a path means up one folder level

As you can start to see the relative paths would find the same locations regardless of drive letter but always the same structure.

The comparison with C# is not applicable because C# isn't looking for other software you have installed in any old location and is not looking for arduino libraries that can be located with the ide, with the hardware defs and also under the mydocuments\arduino\libraries folder.

Hopefully the problem is starting to make more sense now? C# projects use dlls in global window assembly cache or as referenced under references. If your references point to projects that are in entirely different locations then you have the same problem with source control but also the compile would break which it doesn't with Visual Micro.

Visual Micro does have the ability to bring libraries and cores locally into the project but you will still have an issue with the toolchain includes which will reside under the arduino ide or under c:\users\appdata\local\arduino15\packages folder.

Aside from the serial port, that you rightly mention, the paths for intellisense should be rebuilt each time a project opens. Yes this means that the project will be checked out and there isn't much can be done about it. Visual Micro is more intelligent when it comes to compilation because it doesn't use visual studio but for intellisense we can only populate the project properties because that is how VS works.

I hope this makes more sense now? Is intellisense broken when you open the project on a different machine after getting the latest sources from git? If so this suggests a bug in visual micro because it should be rebuilding the .vcproj paths each time a project is opened

I think relative paths could work, but the Arduino core files and the libraries files and hardware specific information such as serial ports should be kept in another file.

As far as I can see a Visual Studio C# project works with a .sln containing the compilation information (x86, x64 and etc.) and the relative path location of each .csproj.

On each .csproj you will find some metainformations and relative paths to .dlls to be included and .cs files to be compiled, ALL of them with relative paths.

I am sorry I wasn't clear about the relative paths before, I was in a hurry to answer you. Yes I think they work, specially because that's the native way VS works.

I think Visual Micro should have a folder of it's own were it keeps central information for all projects (such as Arduino core files and libraries locations) this doesn't have to be shared with every project or repeated everywhere, just one configuration file for the machine itself, under a Visual Micro special installation folder. Than follow the same architecture of VS, with relative paths on the project and solution files.

I can't answer your question about intellisense right now, I have messed up with some libraries and I am getting errors on my machine anyways, but I don't think there are any issues with intellisense so far.

Hmm. There are lots of different cores and libraries and you can install more to various locations as documented on arduino.cc and known by each hardware and library author. For Microsoft you install a .net framework which sets everything up but you can unzip and arduino ide or update hardware via board manager or from zips so its complicated.

What you say makes sense but I think you might be able to organize your installs better so that relative paths then give you the desired end result.

For example the arduino ide can be installed via zip and placed in a known place relative to your project folders. The arduino sketchbook folder (normally mydocuments\arduino) can be set to another better placed location. If you are using board manager downloaded hardware installations then create a folder called \portable below the arduino ide and both arduino and visual micro will download and install new hardware into that folder instead of the users\appdata area.

So you might end up with a folder structure like this

MyArduino
      Ide
      Sketchbook
      Projects

Remember that relative paths can't work across drives so you need to use the same drive for everything related to projects. The sketchbook folder is the default (optionally) location for arduino sketches but also contains the user installed libraries and a few other things so it can't be ignored.

Lastly if you had two projects linked together in c# you would be hitting the same issue if they were located on different drives.

I am always looking at how things can improve in this area so relative paths where applicable might be next on the map.

I understand your concerns but I still see room for improvement.

I dare say if someone uses Visual Micro he doesn't have to rely on much else for Arduino development. I also dare say most people place their libraries on the same folder (usually the folder arduino says them to place).

This way Visual Micro could have still a central file for all the libraries with absolute paths, the IDE only need an "add/remove" feature to write the absolute paths and names of the libraries on the central configuration path. If a library was moved, it's just a matter of removing it and adding it back again or editing it's location.

On the project specific file you just need a reference for the library, a key, matching it with a name or a hash of the library, than Visual Micro searches for this "key" in the configuration file and all is linked and decoupled.

For me relative paths should be enough, I am targeting more the "optimal" architecture for the IDE itself.

I think relative paths will help but the ide uses the paths in the vxproj not visual micro.

Visual micro can only look at the code to determine which libs are required but the ide needs the paths. So they will always have to exist.

I think if you adopt the folder structure I recommended then relative paths would be the same on all pc's

Yes, I agree this will solve my problem, but still I see this as point case scenario solution, and not as the architecture should be.

I never said the paths have to be extinguished, I just gave a new idea of how they should be organized, but if this is too much to implement, I understand.

To be clear, the optimal structure I see in my mind is something like this:

.vxproj (one per project):
- Collection of relative paths to the files included on the project
- Collection of library keys (references) needed to compile the project.

.vmconfig (one per Visual Micro installation):
- Collection of absolute paths for libraries, as a dictionary using unique keys (references) for each library absolute path. Keys can be a SHA256 of the library structure for assuring it's uniqueness.
- Absolute path to the arduino core files on the machine.
- Configuration information like the last selected Serial Port.

This way all is linked, independent and intellisense can be rebuilt the same way, just by consulting these 2 files....or am I missing something?

To be fair, this would mean "extending" Visual Studio current functionality, since if I add an external library to a C# project it will look for it using the same folder structure approach.

This usually don't bother anyone because most libraries use Nuget packages this days witch solves this issue.

Hi,

Please keep in mind what I said about the fact that the compile does not use the vcxproj for ANY paths other than included project sources (which all use relative paths).

The .vcxproj settings causing you concern only apply to allow visual studio intellisense to work and therefore the paths must be where microsoft want them.

This is why the paths in the project are recalculated often and are specific to each machine. The proof should be that you can open the tfs project from any machine and it will still work correctly.

The only issues should be:-
an automatic checkout caused by updating the paths
project port

Do you agree with the two issues and that both intellisense and compile work okay as is?

I think what you really want is to have the arduino cores and libraries installed as a new visual studio "language engine" so it know about it and treats it as different to the c++ projects we "hijack" for arduino. This would be a considerable job to implement, it's a lot easier using standard VS C++ projects with all the goodies they bring but also allows the huge range of extensions written for C++ to work with arduino.

Hi,

I am having a similar issue. I have the *.vcxproj file under version control. Even when I only work on one computer, there are random changes on the project file that don't appear to be triggered by my actions.
The changes are in the the properties: AdditionalIncludeDirectories, ForcedIncludeFiles and PreprocessorDefinitions that have been mentioned above. Some times the changes are just in the order of the tokens. Also, the port and "UserProperties" section look as additional potential for these changes.
The result is that it is difficult to cooperate and that changes to the repository are created when I have not made actual changes in the code. This doesn't affect compilation, just a work-flow issue.

Based on my understanding of VS conventions, the *.vcxproj should only contain non user specific settings. For any user specific settings (paths, ports, board type, etc) there is the *.vcxproj.user file.

My current *.vcxproj.user file is just an empty shell


Code (html):

<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">   <PropertyGroup /> </Project>

Is it possible to move the relevant settings there, via the add-on or manually, and have them stay there? Any experience with that?

Regards,
Arik.