Add MSBuild property macro support to build event properties

[vsfeedback]

This issue has a corresponding ticket on Developer Community. Please vote and comment there to make sure your voice is heard.

---

The legacy editor provided a list of MSBuild properties:

The new UI does not provide this convenience to users:

[StingyJack]

Can someone explain the reason why they feel its acceptable to ship a replacement that has less functionality than it did before? For a company that is so afraid to break backward compatibility that they wont start reporting unit tests as failed when they have failed to execute, having something that was directly user facing go missing without an immediate replacement should be a giant red flag.

[StingyJack]

Also, how is this supposed to work ???

when you cant vote on closed issues.

[drewnoakes]

you cant vote on closed issues

I've passed the feedback about voting on closed issues to the team who owns the migration of tickets from Developer Community to GitHub, with a suggestion to fix the misleading comment.

For issues in this repo, we track votes in GitHub, so there is no need to vote on the feedback ticket.

[StingyJack]

we track votes in GitHub

Does this include the relevant docs pages?

[drewnoakes]

If you mean the tracking of documentation issues, then so long as those docs are backed by a GitHub repo, you can open issues or PRs directly on that repo. Is that what you were referring to?

[StingyJack]

@drewnoakes - Maybe? In this case I opened an issue on the docs page for the new pre/post build screen asking that since the macros are not available in the program anymore that they should be available as reference documentation. So would you count that as a vote toward this (I'm not the only one with reported issues against that docs page,)

[drewnoakes]

The docs team are working through the help pages linked to from the properties UI, from most to least clicked. We have some of the new experience documented now, with more underway.

In the new UI we bring the user cost to build properties by showing both the unevaluated expression and evaluated value when they differ. Our hope is to provide a replacement for macro editing that works on all properties, not just build events.

[StingyJack]

@drewnoakes Yeah, but your collective hope has reduced my productivity. And your plan could never come to fruition, making it permanently permanent (instead of effectively permanent as it is now.)

That shouldn't be happening.

[bitbound]

Bump. I find it bizarre that this was removed.

[RobertBouillon]

This is what these boxes look like in UHD (4k). All this space and I'm forced to write a shell script in this little box, with no reference to the available macros. This seems like a design completely disconnected from the use-case; shell scripts aren't exactly known for being succinct. Unless you've used previous versions of VS, you might not even know macros are an option.

It seems here we've sacrificed functionality for form. While we've forgone battleship gray, this layout is far less readable and organized IMO. There's a LOT of wasted space and I'm not a fan of "doom-scrolling" my settings.

I'd like to see the VS team move this feature forward, not backwards. Maybe offer to link a local project file (.ps1 or .bat) so we can use the IDE instead of a text-box to edit the file? Contextual expansion of variables would be nice, as well, or even allow us to test the script without having to do a build (maybe show the errors somewhere convenient instead of making us dig for them in the output.)

Lots of things we can do to move this forward. Please do.

[RobertBouillon]

Trying to get build scripts working has been a harrowing experience.

1. The settings window failed to save my first attempt at a build script. No errors and not able to reproduce the issue. Had to rewrite my script.
2. Got the script working in VS, but caused dotnet watch run to fail (No clear error message - just inserts Undefined in place of $(SolutionDir)".
3. Tried to use MSBuild instead from this guidance. It doesn't work, nor does it provide an error message.
4. Removed the DataFiles alias and got an error from MS Build: "error MSB3030: Could not copy the file "($SolutionDir)..\Assets\Defaults*.*" because it was not found." $SolutionDir was not expanded so I have no idea why it can't find it (the same expression worked as a batch file).

All I want to do is copy some files from my solution directory to my output directory. I feel like this is what I need build scripts for 99% of the time. Please consider this case when reviewing this feature.

[drewnoakes]

@RobertBouillon thanks for the feedback.

The text boxes in the UI will expand automatically once you have text within them to take advantage of your screen real estate.

The settings window failed to save my first attempt at a build script. No errors and not able to reproduce the issue. Had to rewrite my script.

Is this something you can reproduce? If so it sounds like a bad bug that we would want to fix. If you have a repro, please file another bug here and we'll get it addressed.

$(SolutionDir) was not expanded

Are you using dotnet on the CLI and giving it a single project? Can you open a new issue on this repo with more information about this scenario please? It sounds like a problem for the SDK team, but I'll be happy to triage it.

All I want to do is copy some files from my solution directory to my output directory. I feel like this is what I need build scripts for 99% of the time.

Your .csproj (or .vbproj) file is a build "script" already. You can more easily configure files to be copied via something like:

<ItemGroup>
    <None Include="..\SomeFile.ext" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

This also has the benefit that VS will schedule a build whenever you modify one of those source files, so that the files are copied correctly to the output. When you use a batch file, that information is unavailable to VS and you may be running your application with old files.

If you need to copy multiple files, you can use globbing (e.g. ..\*.ext).

If you prefer using the UI in VS rather than editing your project file's XML, add existing item(s) to the project via Solution Explorer (be sure to select "link" in the file dialog), then press F4 on the item(s) and set the Copy to Output Directory to Copy if newer, which will achieve the same thing.

[RussKie]

I'd like to add my +1 here. The old macros were quite useful, and their absence in the new UI makes crafting launch settings very difficult. A workaround can involve building a project with binlogs, and then discover the variables from there. However, I'm currently working on a project that can't be built from a command line, thus I can't create a binlog, and I'd have to resort to creating a dummy project with the same project- and folder structures, scripts, etc...

[PassivePicasso]

@RobertBouillon thanks for the feedback.

The text boxes in the UI will expand automatically once you have text within them to take advantage of your screen real estate.

The settings window failed to save my first attempt at a build script. No errors and not able to reproduce the issue. Had to rewrite my script.

Is this something you can reproduce? If so it sounds like a bad bug that we would want to fix. If you have a repro, please file another bug here and we'll get it addressed.

$(SolutionDir) was not expanded

Are you using dotnet on the CLI and giving it a single project? Can you open a new issue on this repo with more information about this scenario please? It sounds like a problem for the SDK team, but I'll be happy to triage it.

All I want to do is copy some files from my solution directory to my output directory. I feel like this is what I need build scripts for 99% of the time.

Your .csproj (or .vbproj) file is a build "script" already. You can more easily configure files to be copied via something like:

<ItemGroup>
    <None Include="..\SomeFile.ext" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

This also has the benefit that VS will schedule a build whenever you modify one of those source files, so that the files are copied correctly to the output. When you use a batch file, that information is unavailable to VS and you may be running your application with old files.

If you need to copy multiple files, you can use globbing (e.g. ..\*.ext).

If you prefer using the UI in VS rather than editing your project file's XML, add existing item(s) to the project via Solution Explorer (be sure to select "link" in the file dialog), then press F4 on the item(s) and set the Copy to Output Directory to Copy if newer, which will achieve the same thing.

While using the Proj files to conduct these actions can be a better way to handle these post build events, the tooling in Visual Studio for that experience is non-existent. Which brings us back to the original reason this was opened, the visibility of Macros.

I've done a ton of CSProj based build control and I agree it is a superior solution, however Visual Studio's ability to provide context assist is limited to pre-defined tags. We don't get any assistance for attributes, available macros, custom tag groups, or anything like that. So we can only refer back to the documentation for lists of things which should just be made available via Intellisense/context assist.

This issue is primarily about discoverability and visual studio actively removing discovery from the interface. The current setup is unwieldy and promotes errors by not providing a good context assist experience.

[RobertBouillon]

I want to add that I think this is a great opportunity to expand and evolve Visual Studio. Maybe I think too ambitiously, but maintaining feature-parity with older versions seems like a low bar. A better solution may be possible with less work if we're creative.

Why embed a window of code into the properties page? VS has an editor, can these scripts be opened in the editor? Do they need to be command scripts, or could we use Powershell? Do they need to be scripts at all, or could we write C# classes?