Add ENV var support

[dbgarlisch]

Similar to command line args, being able to define and manage and group ENV vars on a per-project basis would be spectacular.

For debugging, I often find myself needing to change env vars at the same time I am changing command line args.

My debugging life would be much simplified and less error prone if I could group them together.

Basically, controlling Arguments, working directory (#98), and environment on a per-project basis would be perfect.

[vrubleg]

As an idea how it could be added to the current interface. All items in the table could have type, by default the type is arg/cmd (it could be displayed on a 16x16 icon before text, like groups of parameters have the icon of folder), but it could be changed to env (where the item should be in format NAME=value or NAME= for empty environment variable) or to dir/cd/wd (where the item is working directory, relative to project directory as VS does by default). Changing type could be done from context menu of a row (maybe it's simpler to implement), or type icon could work as a drop down menu with 3 options.

Working directory should be selected by radio buttons instead of checkboxes. If a group of parameters have a working directory inside, the whole group should use a radio button then (automatic exclusive mode). It can be useful when you have a few sets of parameters for testing (e.g. for different use cases) that should use different working directories.

It's just an idea how it could be integrated into interface without bloating it. The plugin is very convenient and valuable even in current state, support of setting environment variables and working directory would just make it more powerful and cover all possible cases related to testing command line programs.

[Irame]

That's funny I was thinking about the exact same solution for ENV vars.

But I think that the solution for working directory isn't that easy.

• If you have multiple different groups with working directories than we also make sure that only one is selectable.
• If there are multiple working directories in different groups for different "Project Configurations" than they could be selected at the same time because they will never be applied simultaneously.
• But what happens then, if someone changes the "Project Configuration".

My "solution" would be to add a option like "Working Directories" to groups but only one group can have this option set. This group then has exclusive mode enabled and everything inside it is treated as a working directory.

[vrubleg]

Maybe it can be resolved in a simpler way.

It is possible that there are duplicates of ENV variables. It is safe to assume that the last ENV variable with the same name wins. Similar approach could be applied to working directory: the last active one is actually used. Unused duplicates of ENV variables and working directories can be just grayed out in the table.

[Irame]

implemented in e5a6599

[dbgarlisch]

Thank you!

[Irame]

You're welcome!

I have a question about a feature. I thought about adding the option to change an item from CLA to ENV and back (right now, to create an ENV item, you click the small arrow next to the plus-icon and choose "Add new Environment Variable"). I added this feature but then removed it because I thought it would make the context menu too crowded. But now I think that when you copy and paste text or files, it only makes normal CLAs. Would giving an option to change the item type be a good way to include this function for ENV items without bothering regular users too much? What do you think?

[dbgarlisch]

I am not understanding what you are describing.

Maybe after I have had a chance to use the new env feature, I will be able to give a more informed answer.

Is there a release date for the env feature?

[Irame]

Ok sorry I didn't describe it properly. I think I will add the option anyway and you can let me know what you think.

I think I will release a new version in the next two weeks.

[Irame]

FYI: This is now available in v2.6.0

[vrubleg]

Looks great, but does it support VC++ projects? I tried to test it, but seems like an environment variable is not set, at least getenv returns nullptr instead of the string that I set.

Related to UI, I think that working directory could be handled the same way. Now you can create a few environment variables with the same name, and I guess that the last one should win. The same approach works for Working Directory. As a nicety would be great to grey out lines that are actually not active because of this (and because of current project configuration also), but it is not mandatory. It is already a great tool for development of command line utilities anyway.

[Irame]

Did you enable environment variables in the extension (either in the options panel or the settings dialog)? I disabled it by default so existing projects don't break. I was thinking about a button or something to import existing variables when activating this feature but for now you have to add them manually.

As for the support of VC++ projects. It depends on the debugger used. There is a list at ProjectArguments.cs:159 wich contains all supported debuggers. Missing flavors can be gathered in issue #155 I created for that.

[vrubleg]

Yes, it was turned on. I restarted Visual Studio, and it started to work. Maybe initial setting values were cached somewhere and updated settings weren't taken into account.

[dbgarlisch]

Just updated to the new ENV version.

It.... is.... spectacular!

Having both ENV and command line args in one place will make my debugging life SOOOO much simpler and less error prone.

Thank you again.