Hi

I am sorry to sound arrogant but my intentions are good. I would honestly consider doing these if Visual Micro was my own company and I am not writing this as a user point of view.


Business Related:
1) I would treat Visual Micro as a brand. Based on current website it is very unclear if this is Arduino extension or actually a stand alone extension. When you read the cool features, all of the sudden this is not anything close to what Arduino is considering the philosophy behind products/brands. 
I can even see the day that Visual Micro has an option to "export" a normal C++ project as an Arduino sketch/library and I do see that things are going towards that direction even if it was not your intention.
The reason I think Visual Micro should become a brand is mainly because this is nothing a typical Arduino user should come across. Arduino IDE made things simple so anyone can use it with an easy learning curve, where as visual micro running on Visual Studio is totally different. The learning curve for Visual Studio is unbearable for typical Arduino user, unless that user is going to be an Engineer/Programmer or an employee who has to develop for Arduino or the compatible boards.
I think any attempt to make this Arduino will fail because the philosophy is very different behind the 2 products and I think Visual Micro should be a brand for its niche market.

2) I would focus fully on my niche market.
Knowing the niche market is very important, I do not have access to your data but I think I can predict what your current paid customers are:
i) hobbyist who use Arduino like boards. This group should have few different sub categories:
a) Users who have seen outside arduino IDE and look for a better IDE.
b) Users who just want to try new things and mainly for learning, but they fall in love with visual micro and end up paying for it.
c) Users who are familiar with VS (or other proper IDEs) and when they started looking at Arduino they came across 
ii) Companies which develop for Arduino like boards.
iii) Using this as an educational tool. (I do not think this has been done officially but I do see the potential and I am not sure if it has happened already)

I cannot think of any other possible case. But Also I do not think this is a small niche. I just think that knowing the niche, Visual Micro must focus everything towards these customers and everything should be done for them. For instance the current documentation is not coherent. I know you have spent a lot of time for it but it lacks in consistency. 
For the documentation I would create 2 different sets of documentations. First I would create documentation for i)a) and i)c and ii. then I would focus on documentation for i)b and iii. The reason is that the first group are easier to write for and they may help significantly as the online community. All they need to know is how to actually develop code in Visual Studio environment. This group know what .cpp and .h file is. They know what .ino is and they understand where library directory is. 
But there is one thing they do not know and it does not seem apparent. How do I combine my version control with Arduino like file structure and Visual Micro. To give you on neat example, If I am developing libraries but they are not tested yet how can I make sure I can use the debugging features in them? If I make them arduino library (in library directory) then debugging won't work. Should I use Arduino Shared Project or Arduino Project? What would be the different if I add a Arduino Project as a reference to a solution or Arduino Shared Project? The answer to these question may exist but please read the later parts on why it is very hard to find it. So I would actually provide them a guide on how to develop with best practices. These best practices are very needed considering all the file inclusion magics by Arduino. Also, clearly explain what file structure is accepted in Arduino and how Visual Micro differ. For instance 'src' related stuff. A clear guide + best practices on how to take the under development project to become a library. (considering the file structure and so on). So I would say a guide on how to develop efficiently is very needed because you have the big picture better than anyone else.
Then you can focus on writing guides for i)b and iii. Remember you do not need to do Arduino's job but you can tell how to follow any Arduino tutorial by just teaching them how the basic stuff in Arduino IDE happens in Visual Micro and Visual Studio. Since most tutorials for arduino have very little to do with IDE, I think this should be relatively easy. 
You may also consider linking a visual studio guide that does not focus too much on things we do not need in Arduino level. I could not find one, because I do not have the big picture view that you have yet.
After making enough money you may consider making tutorials to teach Arduino + Visual Studio + Visual Micro all together for maybe engineering/computer science students in their first/second year of university. The quality of your guides can justify the price. If you can get unis on board then that would be fantastic.


Online Appearance:
1) Currently your website and Forum does not rank in Google search. I think you need to look at Search Engine Optimization (SEO). It is not hard but once you learn the basic every content you generate have higher chances of getting ranked. I do not know what platform you have used for the website otherwise I could help you choosing a plugin that helps with SEO. Also Google search console can help you with SEO.

2) your Forum is loads very slowly and the search function is not that great. I think if you just use stack overflow with tag for Visual Micro and just maintain things in there, there will be 2 benefits:
1) amazing SEO
2) amazing search features

3) Get SSL certification for your website. It cost less $150 but it helps your website rank higher in google search.


These are things I would to for Visual Micro and I think you guys are up to something very cool specially considering the debugging tool. I work with many students and we used to use Sublime and Stinno plugin. I was never convinced to purchase Sublime but I have been using your product for one week and I think it is very easy to sell this product if the right marketing plus what I said above is done. I am not as experienced on the marketing side so cannot provide any significant help. But I understand and see the value of visual micro.

BTW I am going to purchase your product very soon, as soon as I figure out a proper method to combine project + version control + visual studio tricks and then creating libraries out of it. I am sure I will find an easy way with my current level of understanding from everything but still I am digging for an easier integration. If you happen to have any answers written for the above issue, my purchase happen faster and I am sure I will not be the only one.

(Have to rush for a meeting now, sorry if there are typos and errors)

I am glad you take in the positive way.

I would like to show you my highest level of respect for keeping this project alive while being a one man army. I have been and pretty much am in similar condition right now and I can understand how tough it is. It takes huge amount of dedication.

I will surely drop you an email so we can keep in touch specially because if things go well on our side, we might be able to use (as paid customer) + promote your program in new communities and hopefully help you with paid customer. I will write more in the email about this.


please let me know if I understood shared projects correctly.
Your debugging feature was not working on libraries because libraries are pre-compiled. So you wanted a quick way for users to create a "local" version of the library so that the debugging feature can be applied in that local library and changes would not affect the main library (if files are created under the project). Also if the user just add files as existing files by creating the link he can technically change the library files straight away without the need to copy past anything (The only issue may be file permission but we already know the work around for that). If I understood this correctly, this is a very smart solution.


Regarding the version control side of the stuff, there is something to consider also. Should a user use something like SVN/Git to only take care of .h .cpp .ino files or should he/she use Visual Studio built in. There are both advantages and disadvantages if you consider each case and to be honest I am not familiar with Visual Studio's version control and I am not a version control guru yet. So I might have be very wrong on this one. But from my point of view I can see both advantages and disadvantages for each solution. I would love to break down the advantages and disadvantages but I think I still need more time to think about this.


I am still trying my very best to integrate everything together to make it as neat as possible and I definitely let you know the result to receive your suggestions and fine tune and maybe later we can make a guide out of it.

I would like to thank you once again for keeping this product alive and I hope it becomes a financially sustainable project so that you hard work over the years finally pay off.

Now one may argue that I have 2 Apple library folders, one under Apple_Testing and one under Fruit. You are right we have two versions but since they are both under subversion with no changes you can easily commit/update changes from either place. The only down side is that you have to keep the folders updated to latest version from SVN from all src sub folders to have the latest version. The other problem is that making very large project still need you to do couple of get solution from SVN for each level of the library. It may be time consuming but at least you have to do it only once when you start the project.

Also take note SVN does not include Apple in Fruit and this help with a lot of mess but the down side is that you have to recursively add to get a big project working or change the include path to avoid multiple copy of the same project. I am not sure which one is better at the moment but will let you know.

Also when I include files I use the following format to make it easier for the future.

////////// Internal Includes //////////
Files that belong to this library
///////// END: Internal Includes //////////

////////// External Includes //////////
Files that supposed to be external libraries later in released version
////////// END: External Includes ////////// 

I guess this can save you a little bit of time.


Now, am I happy with this solution? In a way. I spend one week and played around and learned some stuff in visual studio news feature and also decided if I go atmel or visual studio, so in a way I am happy. If there is a neater way to do this, I would love to hear about it. 
If Debugging feature is added to libraries, this guide becomes 2 miles shorter in length  But I think Tim is already doing so much work for Visual Micro so i will patiently wait and use the method above.

Now one thing can help with the above procedure and I tried to do it but it did not work. Tim this may be a 30 minutes problem for you, but I have spent 12 hours and so far no success and in a way I gave up because I cannot think of a way to solve the problem. I was trying to make a template for Visual Studio to create the .ino file and src folder with .h and .cpp files in it, but it did not work. I got to the point where pretty much things worked but the .h and .cpp file are always missing from the project but exist in solution explorer. It was my first time making Templates and I noticed you should have done a lot of work for current templates specially I found it very difficult to continuously extract and compress the template file. Maybe I was doing it wrong but it was tedious.

I am sorry for the very long posts but I hope I either help others or someone come and tell me there is an easier way, 

Hi

Actually this is not Visual Studio issue. The mess explained above is due to the following reasons:
#1) Arduino does not allow a sketch .ino file to include header from other directories.
#2) Debugging does not work in library sub folder. (this would be no issue if #1 did not exist)

In a typical Visual Studio case:
1) You can add any project from anywhere to the your solution as a reference and use the files.
2) Debugging works every where. (This does not really matter if any file can be included)

Also the issue with version control exist only due to Arduino treatment of .ino file as stated in #1. If debug was supported in library folder, this would not be an issue since library folder is treated normally by arduino. So by solving either #1 or #2, the problem would disappear.

Regarding the shared project you are correct about it being new, But it was actually supposed to solve a different problem.

Regarding the include path changes. It must be changed when the "sketch" is released as library. I actually suggest you try developing 2 libraries (1 depending on the other one) while having the debug feature working. Then make an .ino file for the higher level library which calls the lower level entities.
I am sure as soon as you start doing that, you will see the problem. The reason I spent 1 week for this is because so many things that you think they work as a typical Visual Studio projects, they actually do not. (this is not Visual micro file, this is Arduino file management related as stated in #1)

If you want I can do the example above with one Visual Studio project and one Visual Micro project to clarify the issue.

Case 1:
Have you made the library a shared project? Yes. 
Have you added a reference to it in your master project? Yes
What is the folder structure of your library? libName/src? Presented in case 1
Does your library have a library.properties file in the root? yes
We call this Case 1 and the files are attached. Problem is Shared project library fruit cannot use Shared project lib apple.
The sketch project attached named "testingFruit" is located in my sketch directory. You may have to add the reference projects again because the path will be different in your machine.

When you build the project you get the following error:
(deep search off)
Severity      Code      Description      Project      File      Line      Suppression State
Error            13:20: error: 'getNApples' was not declared in this scope            C:\Users\alireza\source\repos\Fruit\src\Fruit.cpp      13      
(deep search On)
it complains about deep search.


Case 2:
Have you made the library a shared project? No. it is a library located in library of arduino.
Have you added a reference to it in your master project? Yes
What is the folder structure of your library? libName/src? yes
Does your library have a library.properties file in the root? yes

based on this http://www.visualmicro.com/forums/YaBB.pl?num=1455225504 Debugging cannot happen on this library, unless another shared project is made from the library. Then by doing that case 1 occurs.


PS: I was asleep (1:30 AM) but after seeing your replay, I came back to office to make sure what I said is correct about shared projects not being able to include each other. I was sure it won't work because I tried it extensively but wanted to make sure I am not wasting your time.

Hi

1) When you #include an Arduino library you should not specify the \src sub folder.
There are too things to consider in here.
a) It is Visual Studio shared project, which is supposed to be an Arduino library, but we add it as an Arduino library and not Visual Studio shared project. (It is not bad but it is good to have it said explicitly)
b) Before you compile the code, intellisense finds everything to be wrong add draw a led line under it. (this could be the reason I have not noticed it in my personal time. Also when you want to include the shared library projects intellisense only suggest the "src/Apple.h" and does not suggest "Apple.h". I guess this is also another factor why I treated the shared project like Visual Studio entity). Again I do not think this is bad, It is just good to know.



2) In Fruit.cpp you are missing #include "Apple.h"
I tried adding "src/Apple.h" as suggested by intellisense  and it did not work. So I just removed it. Again the fact that intellisense before the first compile find everything wrong in a way convince me that this is the Visual Studio entity. Again nothing wrong with that, I guess it is all good.


3) Visual Micro rebuilds lib paths when projects open if required
Okay. I think that is an expected behavior.

4) Visual Studio shared project paths are stored as relative path not absolute.
thank you for information on that.



Actually the experience above makes so many things easier. The long post I have describe a (now) stupid workaround for achieving what is achieved above. I guess this is pretty solid, I just have to test with nested files in src to make sure we are all good and probably few debugging points so that I can start porting my code. Just one concern to think about is that in a big project you have to individually open and reference library projects (referencing can happen all at once). That means even if .ino is not accessing that library directly, you still need to add it to the project for the use of other libraries. But honestly I can live with that all fine.

After my initial test and code porting (to make sure I have everything sorted), I would love to pay back for your time and effort by a crash course video presentation or article but I let you decide for that. On top of that you have a new loyal customer. If anything needed just let me know.

Hi tim

Thank you for the reply and separating the threads. I am sure it will help the future user.

Just to clarify something, I am just looking for a way to develop libraries for Arduino using visual micro while the debugging is available in under development libraries and I wish for minimum file changes when releasing the under developed library as official Arduino library. (as stated in my first post)

I have done extensive testing over the last 15 days to find what seems to be the best solution to replace Arduino IDE. I did a lot of testing between Atmel Studio and Visual Studio to pick a winner. Then I have spent all my time figuring out a solution for the paragraph above. I have already found some interesting information regarding the debugging that I will post on the other thread since it is focused on debugging in shared projects. But in summary, you can debug a shared project but not a shared library for more info check the other thread.


Interesting stuff start here

One of my initial finding was that shared libraries cannot be debugged and that is why I just used shared projects instead because shared projects can be debugged (evidence provided in other thread). Now the interesting thing is that shared project cannot include each other under some circumstance. 
1) shared projects can include each other however a nested shared project cannot include other shared projects which are not nested.
2) Non-nested shared projects can access the shared project with nested files.

After receiving Tim's suggestion to use, shared libraries, I thought maybe I have done something wrong with the debugging stuff and probably I should spend more time on it. So I tested so many different file structure to make sure shared libraries are working without an issue. Today after realizing that shared libraries are new and debugging has not been tested on them, I realized that shared libraries for sure are not going to work in the current version. I had no doubt that my debugging is set correctly, because it was running on other parts of the code fine. So I was back at the problem and started to play around with shared project and accidentally discovered something interesting, I did not discover this initially because intelisense consider it as an error (I had so much respect for it back then  ) but it compiles just fine.
I have attached the files, if you want to test them.
The file structure is like this:
shared Project 1:
Red/Red/src/RedNested/RedNested.h
Red/Red/src/RedNested/RedNested.cpp

shared Project 2:
Blue/Blue/src/Blue.h
Blue/Blue/src/Blue.cpp
Blue/Blue/src/BlueNested/BlueNested.h
Blue/Blue/src/BlueNested/BlueNested.cpp

lastly a sketch in Arduino sketch folder named: ColorTesting.ino

In ColorTesting.ino includes are:

#include "src\Blue.h"
#include "src\BlueNested\BlueNested.h"

#include "src\RedNested\RedNested.h" 

In RedNested.h I decided to add BlueNested.h, the include is:

#include "../../src/BlueNested/BlueNested.h" 

In Blue.h I wanted to include RedNested.h, the include is:

#include "../src/RedNested/RedNested.h" 

In BlueNested.h I add Blue.h, no brainier there but just to be clear the include goes as:

#include "../Blue.h" 

It was initially very surprising because even after the compile the intelisense still consider it as an error. Good news is that the drop down suggestion still does its job correctly and suggest you the functions from shared project nested files.

I actually understood why this works eventually. Shared project content is copied to project location, I knew that but never looked at it from the correct point of view. Since the files are copied that means that the shared project are going to all sit next to each other. The only trick is that they are copied without the root folder. That is why only one of "../" is needed in include line and we do not mention the root folder name.

Now if I use this method to develop Arduino library the code can then be released as an Arduino library easily and only one change is needed, the include paths have to be modified. all of "../" should be removed for including external files, since they also become library in Arduino and they can be accessed without the "../"s

The debugging features are also working! You can check it out in the test project attached. I have already added breaking points and "complicated" (proof of concept) function calls.
Just make sure the Folders are not placed next to each other so that the relative paths do not produce the same result as our include lines. (even if they end up same, it should work. I have tested loosely)

I can now die in peace. Thank you Tim for the awesome work. Without you this would not be possible.


Edit1: Attached file were correct but the structure I typed was wrong and I added "src/" to them.
Edit2: Take note your shared project must have all its files in src, otherwise whatever explained above won't work.
Edit3: Includes can become simpler. I am currently porting my old code and once I am done with that, I can probably show you the most efficient way. Although with description above you should know it already.

31 days till I can confidently say that I have a grip on the tool chain. I think it should have not taken so long and I wish there was more feedback on my proposed solution. However it pays back very well, specially considering how awesome Visual Studio is. I have not used debugging much because I had to port 30,000 lines of code but the visual studio features make life easier on so many levels. I have ported my libraries and have 2~3 under development now and the it is considerably faster than using the Arduino IDE or Sublime + Stino. (I was not using any additional extension on my sublime and this could be the reason why Visual Studio seem to make a huge difference for me)