Smart Commandlines Keep Getting Wiped Out

[eddieparker]

After a recent update my command line arguments keep getting wiped out when I sync from our perforce repository and build. I'm not clear how I can get better data or repro here, so I'll detail the things that are important.

My workplace doesn't check in solution files or vcxproj's - we generate them from a different source file (sorta like CMake, but proprietary). We use perforce for revision control.

My normal workflow is to sync from perforce, generate the vcxproj's (if there are changes), and then VS reloads as part of the process.

In the past this has been fine with this plugin, but recently it seems to wipe out my settings and I lose all my command line arguments.

I've started to noodle with the settings in this plugin in the hopes it would fix it but it still causes me issues. I'm also quite confused by the settings:

• "Save Settings to JSON" by default doesn't seem to be clicked but enable version control support and "use solution directory" imply it will save to json?
• "Save Settings to JSON" sounds like something I'd want on all my solutions, but I can't seem to make it a default setting in VS and have to reconfigure it for all my solutions individually? (We often create temporary solutions)
• I'm unclear what the 'solid square' means in the checkboxes. Does this imply "use default" (i.e., whatever the "Default:" says?)

• Here I've tried to find any settings that would be deleting the settings and disable them, but to no avail.

Any logs or whatever you need, please let me know. I don't know how to repro this reliably but it happens every couple days and it's pretty aggravating. :(

[Irame]

Hi, thanks for using the extension and reaching out about your problem. I was inactive for a while on this project, I'm sorry. Im not quite sure what you mean with "it seems to wipe out my settings", which settings are wiped? The settings inside the Dialog of the first screenshot you provided? These settings are stored inside the .suo file inside the .vs folder next to the solution file. If I see this correctly, then this file is lost every time you regenerate the solution. The problem I have understanding your issue right now is the fact that it worked before, even though the settings where always saved in the .suo file (even in older versions).

The solution I would recommend is to save the settings to a JSON file and then save this JSON file to your repository and copy it in you generation workflow next to the generated solution. This also ensures that everyone working on the project uses the same settings.

The only drawback there is, that you have to edit your original file manually if you change some settings. You could use symlinks (or something similar) for that.

If you can think of a better solution, please tell me.

To clear up some confusion:

• The Save Settings to JSON is checked if there is a JSON file present. It will create one if you check it and delete it if you uncheck it.
• The solid square means "use default" where the default is configured in the options (the second screenshot you provided).

[Irame]

I would also appreciate it if you could use the latest beta version 2.6.0.3 for testing.

[eddieparker]

Hi, thanks for using the extension and reaching out about your problem. I was inactive for a while on this project, I'm sorry. Im not quite sure what you mean with "it seems to wipe out my settings", which settings are wiped? The settings inside the Dialog of the first screenshot you provided? These settings are stored inside the .suo file inside the .vs folder next to the solution file. If I see this correctly, then this file is lost every time you regenerate the solution. The problem I have understanding your issue right now is the fact that it worked before, even though the settings where always saved in the .suo file (even in older versions).

Apologies, I was unclear. When I said "wipe out my settings" I meant the command lines I've stored disappear. I normally have a myriad of command lines depending on what I'm testing, and upon syncing I sometimes lose them all.

The solution I would recommend is to save the settings to a JSON file and then save this JSON file to your repository and copy it in you generation workflow next to the generated solution. This also ensures that everyone working on the project uses the same settings.

I appreciate the work around but we all run different command lines based on what we're testing and we have a tonne of different command line arguments - adding them all would just be noise. Those of us who use this plugin tend to curate the command line switches we need.

Ideally I'd love if there was a way to get logs about why the command lines are being deleted.

I'll try upgrading to the beta to see if it's better.

[Irame]

Hi, thanks for the clarification.

The way you enable logging is described in the wiki. I am not sure if you will find the cause of the deletion in the logs. I'll try to improve the logging regarding this issue but for now it's very much possible that the logs don't give you enough information about this.

As a last resort you could put the .args.json outside of the generated folder by setting a custom root path in the settings. With this you would only have to include a non changing `.ArgsCfg.json` file in you project generation step which would look something like this:

{
  "UseCustomJsonRoot": true,
  "JsonRootPath": "..",
  "VcsSupportEnabled": true,
  "UseSolutionDir": true
}

This file needs to be copied next to the solution file.

[jrdmellow]

I have frequently experienced an issue like this as well with generated project files. I think it may be the same root problem as @eddieparker

In my case, I'm working on an Unreal Engine project that has it's .sln and .vcxproj files generated by an external application (Unreal Build Tool). In the past I've also had this issue with projects using using Sharpmake and Premake to generate Visual Studio files.

When the project generation occurs, the .vcxproj's GUID seems to be mostly deterministic, but sometimes a new GUID can be created.

Initially, the saved arguments disappear from the UI, but they're still in the .args.json file. If you catch it before the .args.json is overwritten, you can swap out the GUID and resume where you left off. Otherwise, after some time working with the newly generated GUID, it seems like .args.json is cleaned out and only arguments matching the loaded .vcxproj are kept.

Also worth noting is that in my experience the GUIDs are not deterministic between machines, which makes it impossible to share configurations via source control when using generated VS projects.

[Irame]

Thanks for providing the hint with the changing GUID. Maybe a solution would be to allow the project to be matched via the name if the GUID is not found, would that be sufficient in your case?

[jrdmellow]

I believe that would work for the cases I'm aware of. Project names are required to be unique by the generator (UBT/Sharpmake at least, and the same should be true for Premake, IIRC), so there should be no chance collisions.

I'm not sure about project name uniqueness requirements in Visual Studio solutions in general. Maybe it should be an opt-in behaviour.

[Irame]

I don't think it is necessary to make it a opt in feature because it is only matched if the GUID could not be matched. The only thing that could annoy people is the changed file if they use the solution file and not project specific files.

I implemented a first version (v3.0.3.1) for you to test if you want.

[jrdmellow]

I've been using the version you uploaded for a few days and I haven't encountered any issues so far but I also haven't checked if the GUIDs have reset on me yet. It happens naturally fairly infrequently, at least with UBT.

I should be able to repro it by wiping out my generated projects and running UBT from scratch. I'll try that when I'm back to work on Monday.

I appreciate the quick response, btw!