Standard build variables are not replaced in before/after build scripts. #677

TheRealPiotrP · 2017-01-18T10:36:42Z

Moving from https://github.com/dotnet/cli/issues/5095 on behalf of @mdekrey

Sorry if this isn't the right spot; I wasn't sure if the MSBuild repo was a better location for this report or not. Simplest steps are below, but I originally accessed this via Visual Studio, which gave menus for the "macro" variables that did not get replaced. Note that this occurs for both project variables, not just solution variables, as the example uses the dotnet cli.

Steps to reproduce

Create a new project (dotnet new)
Modify your .csproj to have PreBuildEvent or PostBuildEvent that uses build variables as documented in previous C# projects. For example:

    <PropertyGroup Label="Configuration">
      <PreBuildEvent>echo $(OutDir)</PreBuildEvent>
      <PostBuildEvent>echo $(OutDir)</PostBuildEvent>
    </PropertyGroup>

Restore packages. (dotnet restore)
Build the project. (dotnet build)

Expected behavior

Standard build variables should be replaced in before/after build scripts.

Microsoft (R) Build Engine version 15.1.458.808
Copyright (C) Microsoft Corporation. All rights reserved.

  bin\Debug\netcoreapp1.0\
  test -> C:\Users\Me\Source\test\bin\Debug\netcoreapp1.0\test.dll
  bin\Debug\netcoreapp1.0\

Actual behavior

Standard build variables are not replaced in before/after build scripts.

Microsoft (R) Build Engine version 15.1.458.808
Copyright (C) Microsoft Corporation. All rights reserved.

  ECHO is on.
  test -> C:\Users\Me\Source\test\bin\Debug\netcoreapp1.0\test.dll
  ECHO is on.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview4-004233)

Product Information:
 Version:            1.0.0-preview4-004233
 Commit SHA-1 hash:  8cec61c6f7

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0-preview4-004233

The text was updated successfully, but these errors were encountered:

srivatsn · 2017-01-18T20:07:35Z

Not sure if this is a SDK or a project system issue. @basoundr can you take a look?

dsplaisted · 2017-01-18T20:54:26Z

This is because the OutDir and similar properties are set in the SDK targets, so they are not set when the PreBuildEvent and PostBuildEvent properties are evaluated in the project file.

I think for this to work in the previous project system, you would have to set the build event properties after the CSharp.targets import at the bottom of your file. This isn't easy to do now that that import is implicit.

In light of this, we may want to discourage or disable use of PreBuildEvent and PostBuildEvent in SDK projects. The alternative would be to define Targets in the project file, as properties inside those Targets would be evaluated after the SDK .targets files have been evaluated and set the properties.

rainersigwald · 2017-01-18T21:32:49Z

I'd love to disable use of the events in general for many reasons like this. Disabling them for Sdk projects gets a 👍 from me.

Ziflin · 2017-02-11T04:05:04Z

Is there any solution for this? It is affecting us as well. We were also trying to change the Output path in the project settings, but clicking the Browse button crashes VS.

mgwalm · 2017-02-15T22:24:55Z

You cant just decide to get rid of this. I think thousands of users all over the world use it.

Ziflin · 2017-02-15T22:29:43Z

I'm still trying to find out when this will be fixed as we definitely need the pre/post build events to work and to properly pass in the macros/environment variables?

dsplaisted · 2017-02-15T22:41:08Z

@mgwalm @Ziflin I don't expect us to make PreBuildEvent and PostBuildEvent get the final values of properties as OutDir. If anything we would disable them entirely in .NET SDK projects to avoid people hitting this issue.

Instead, what you can do is use targets to do this. Here's an example:

  <Target Name="PreBuild" BeforeTargets="PreBuildEvent">
    <Exec Command="echo Before Build: $(OutDir)" />
  </Target>

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <Exec Command="echo After Build: $(OutDir)" />
  </Target>

Ziflin · 2017-02-15T22:55:47Z

@dsplaisted Thanks! That's all I was looking for. Is there a webpage somewhere that describes the new csproj format?

dsplaisted · 2017-02-15T23:23:57Z

@Ziflin I think some of the documentation is still a work-in-progress, but see https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/ and especially https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/csproj

Ziflin · 2017-02-15T23:25:56Z

@dsplaisted Great! Thank you very much!

StingyJack · 2017-04-25T02:55:07Z

This still doesn't work for things like $(ConfigurationName) either, and that is known before building.

darkurse · 2017-06-21T09:13:07Z

@StingyJack , if it helps this actually worked for me when combined with the solution in issue #1569 ( anwer from davkean ).

The only drawback for me is that these prebuild and postbuild targets are not visible/editable from vs2017 prroject settings UI. And so if I don't tell my colleagues about this fact they won't see my changes and will start believing in black magic :)

rainersigwald · 2017-06-21T13:56:20Z

With dotnet/project-system#2367, the Visual Studio UI will now emit targets for build customization, so adding new steps to new projects will allow use of any properties and items defined at the relevant point in the build.

The new implementation does NOT update existing definitions of the *Event properties, so you might need to remove them and re-add them through the UI to get the updated behavior. If you already defined your own target, 1) 👍and 2) you shouldn't need to take any action, unless you really want to use the UI to manage the process.

DavidHollman · 2018-08-22T13:06:26Z

Is this the same issue as dotnet/project-system#1569 ?

rainersigwald · 2018-08-22T15:34:03Z

@DaveInCaz Not exactly. That bug was fixed when Visual Studio was taught to emit pre- and post-build events using a better mechanism that isn't subject to the constraints discussed here. However, it's still possible to manually use the property approach, which is subject to the ordering-of-property-definitions constraints that cause problems here.

StingyJack · 2018-08-23T04:51:09Z

unless you really want to use the UI to manage the process.

Well, yes. I dont really want to do all the typing required to unload, manually modify a proj file, and then reload it when I can do it in a few shortcut keys. I sure as heck dont want to type in full commands for anything. We didn't pay for Visual Studio so we could have notepad + msbuild.

I'd love to disable use of the events in general for many reasons like this

That doesn't read very well.

I don't expect us to make PreBuildEvent and PostBuildEvent get the final values of properties as OutDir. If anything we would disable them entirely in .NET SDK projects to avoid people hitting this issue.

The issue is that the things dont populate as expected. They are useful things to many people, and I dont see a compelling reason here to make all those users (customers) have to change what was working code before that is now not.

Rabadash8820 · 2018-09-12T04:02:11Z

Adding to @StingyJack's points...

I have zero problem with build events being phased out and build targets being the new best practice, especially if the implementation is as simple as dsplaisted's answer above. All of us long-time Microsoft users could stand to get out of our comfort zone and write some code rather than having a magical UI take care of everything for us, and I love that the "new" Microsoft seems to be embracing more transparent tools that can be tweaked in any text editor, not just with mindless clicking.

All that said, I have two problems with the current build-event situation:

Build events are still present and editable in the project Properties page. If we are supposed to be moving towards build targets, this UI should be removed. People are going to keep using a tool as long as it is available, even if they're not supposed to (myself included, until I saw this Issue).
If this UI is not going to be removed, then it needs to work! What we have right now is a massively breaking change for all moderately complex build pipelines, with no documentation that I know of other than 1-2 year old GitHub issues. That this silent bug still exists in VS 15.8 is embarassing; all you need to add is a notice to the Build Events Properties tab saying "Warning: build variables are not replaced in .*proj files targeting .NET Standard" or a green squiggly in the .*proj editor with the same message.

dasMulli · 2018-09-12T04:32:38Z

@Rabadash8820 Projects using the new project system already get the some new behaviour: The UI will actually create targets. This was added in 15.3 - dotnet/project-system#2367. But AFAIK it doesn't switch from the build events to targets, but it will create and edit targets when you first use it.

DavidHollman · 2018-09-12T11:53:45Z

@dasMulli how does a version # like 15.3 which you mentioned correspond to what is available to a given version of Visual Studio? Thanks

StingyJack · 2018-09-12T12:14:51Z

@DaveInCaz - 15.x is the version number of VS 2017

tamlin-mike · 2019-11-05T10:33:44Z

Just to chime in; an unfortunate aspect of using the XML hackery is the combination of quoted strings and Microsoft-style path delimiters. f.ex:

How should unquoted space characters be escaped?
How should quote characters be escaped?
How should backslashes be escaped?
How are platform-agnostic path separators to be formed?
...

Embedding this into a XML string seems to just have re-opened that can of worms of incompatibility (between Windows and "everything else"), both when it comes to path separators and quoting in general (of both strings and whitespaces).

Moving on, is this documented? I don't mean here, or in the code, I mean in an actual document, something a user of it can depend on.

If run as part of a batch-build from .sln, whether from command-line or VS, is it possible to access properties of a different project?

Example:
Let's assume SDK-style projects A and B, producing A.exe and B.dll, where A.exe and B.dll are placeholder names for platform-specific representations of an executable, and a library, respectively.

I'm thinking of the scenario where you need A.exe to do pre- or post-processing for/of B.dll. Is it possible to access e.g. produced assembly name, to get full path to A.exe from B.csproj, or would you be forced to copy A.exe into a platform-specific known location and reference it using platform-specific pathnames?

If not built as part of a batch-process it would obviously be impossible to reliably do such lookups.

…0190603.1 (dotnet#677) - Microsoft.AspNetCore.Mvc.Api.Analyzers - 3.0.0-preview6.19303.1 - Microsoft.AspNetCore.Mvc.Analyzers - 3.0.0-preview6.19303.1

trivalik · 2021-05-17T13:15:18Z

It is also not possible to access TargetDir/OutDir like this as before it was:

<PropertyGroup>
  <EXT>C:\Program Files\NotExistingPath\</EXT>
  <EXTTarget Condition="Exists('$(EXT)')">$(EXT)</EXTTarget>
  <EXTTarget Condition="!Exists('$(EXT)')">$(TargetDir)</EXTTarget>
</PropertyGroup>
<Target Name="MyAfterBuild" AfterTargets="AfterBuild">
  <Error Text="Will be empty: $(EXTTarget)" />
</Target>

but this works, but require several use in case other target need this EXTTarget:

<PropertyGroup>
  <EXT>C:\Program Files\NotExistingPath\</EXT>
</PropertyGroup>
<Target Name="MyAfterBuild" AfterTargets="AfterBuild">
  <PropertyGroup>
    <EXTTarget Condition="Exists('$(EXT)')">$(EXT)</EXTTarget>
    <EXTTarget Condition="!Exists('$(EXT)')">$(TargetDir)</EXTTarget>
  </PropertyGroup>
  <Error Text="Will be not empty: $(EXTTarget)" />
</Target>

AndrueCope · 2022-10-13T13:39:09Z

..and I've just run into a related issue with VS 2022.

https://developercommunity.visualstudio.com/t/VS-not-saving-project-files/10170893?viewtype=all

Charlieface · 2023-11-23T12:35:15Z

Why is this still an ongoing issue 6 years on?
It would be ridiculously easy to either completely disable Pre/PostBuildEvent, or just convert it automatically to a Target.

The events show up in the Events boxes in the new VS, but don't work as expected. You need to delete/copy out your code, clear the box and re-enter it for the Target to be created correctly.

ajtruckle · 2024-04-11T17:13:51Z

This helped me:

https://stackoverflow.com/a/52977805/2287576

So now I have:

<PropertyGroup>
	<!-- Find Windows Kit path and then SignTool path for the post-build event -->
	<WindowsKitsRoot>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot10', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
	<WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot81', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
	<WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
	<SignToolPath Condition="'$(SignToolPath)' == '' And '$(Platform)' == 'AnyCPU' and Exists('$(WindowsKitsRoot)bin\x64\signtool.exe')">$(WindowsKitsRoot)bin\x64\</SignToolPath>
	<SignToolPath Condition="'$(SignToolPath)' == '' And Exists('$(WindowsKitsRoot)bin\$(Platform)\signtool.exe')">$(WindowsKitsRoot)bin\$(Platform)\</SignToolPath>
	<SignToolPathBin Condition="'$(SignToolPath)' == ''">$([System.IO.Directory]::GetDirectories('$(WindowsKitsRoot)bin',"10.0.*"))</SignToolPathBin>
	<SignToolPathLen Condition="'$(SignToolPathBin)' != ''">$(SignToolPathBin.Split(';').Length)</SignToolPathLen>
	<SignToolPathIndex Condition="'$(SignToolPathLen)' != ''">$([MSBuild]::Add(-1, $(SignToolPathLen)))</SignToolPathIndex>
	<SignToolPathBase Condition="'$(SignToolPathIndex)' != ''">$(SignToolPathBin.Split(';').GetValue($(SignToolPathIndex)))\</SignToolPathBase>
	<SignToolPath Condition="'$(SignToolPath)' == '' And '$(SignToolPathBase)' != '' And '$(Platform)' == 'AnyCPU'">$(SignToolPathBase)x64\</SignToolPath>
	<SignToolPath Condition="'$(SignToolPath)' == '' And '$(SignToolPathBase)' != ''">$(SignToolPathBase)$(Platform)\</SignToolPath>
</PropertyGroup>
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
	<Exec Command='echo "$(SignToolPath)signtool.exe" sign /d "$(OutDir)\net8.0\xxx.exe" /fd SHA256 /du "yyy" /f "d:\xxx.pfx" /p "ppp" /t "http://timestamp.sectigo.com" /v "$(OutDir)" ' />
</Target>

But:

Do we really need all those definitions?
Can I use a constant for my executable name?

srivatsn assigned basoundr Jan 18, 2017

srivatsn added this to the 1.0 RTM milestone Jan 18, 2017

srivatsn added the Bug label Jan 18, 2017

srivatsn unassigned basoundr Jan 19, 2017

srivatsn modified the milestones: 1.1, 1.0 RTM Jan 19, 2017

mlorbetske mentioned this issue Feb 11, 2017

Question: How to setup a post build event script aspnet/Tooling#611

Closed

dsplaisted mentioned this issue Feb 15, 2017

Make PreBuildEvents\PostBuildEvents work using targets dotnet/project-system#1569

Closed

dsplaisted mentioned this issue Apr 9, 2017

$(TargetPath) or $(TargetDir) are empty on PostBuild event on netstandard project #1055

Closed

This was referenced May 3, 2017

Fix VS2017 build bradygaster-zz/downr#28

Merged

Revert VS2017 fix bradygaster-zz/downr#29

Merged

mauroservienti mentioned this issue May 10, 2017

.NET Core assembly loading might fail with FileNotFoundException Particular/Workshop#64

Closed

dsplaisted self-assigned this May 15, 2017

dsplaisted modified the milestones: 2.0, 1.1 May 15, 2017

dsplaisted added the Urgency-Soon label May 22, 2017

livarcocc modified the milestones: 2.0.0, 2.1.0 May 23, 2017

livarcocc modified the milestones: 2.1.0, 2.2.0 May 25, 2017

Neutrino-Sunset mentioned this issue Jun 22, 2017

Project System: AvailableItemName support dotnet/project-system#113

Closed

lruckman mentioned this issue Jul 20, 2017

PostBuildEvent not retaining macro values in VS 2017 lruckman/DRS#4

Closed

twenzel mentioned this issue Nov 30, 2017

SolutionDir variable not resolved during post build event #1777

Closed

jotatsu mentioned this issue Dec 24, 2017

CONTRIBUTION: How to? mRemoteNG/mRemoteNG#691

Closed

livarcocc mentioned this issue Feb 23, 2018

Post build variables empty when executing "Publish" #1987

Open

malaybaku mentioned this issue Sep 30, 2019

WPFのフレームワークが古い malaybaku/VMagicMirror#87

Closed

mjrousos mentioned this issue Oct 17, 2019

Mention that PreBuiltEvent and PostBuildEvent shouldn't be used (since common macro properties don't work there) dotnet/docs#15248

Closed

marcpopMSFT removed the Urgency-Soon label Aug 28, 2021

marcpopMSFT removed this from the 2.3.0 milestone Aug 28, 2021

marcpopMSFT added the Area-NetSDK label Aug 28, 2021

marcpopMSFT added this to the Backlog milestone Aug 28, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Standard build variables are not replaced in before/after build scripts. #677

Standard build variables are not replaced in before/after build scripts. #677

TheRealPiotrP commented Jan 18, 2017

srivatsn commented Jan 18, 2017

dsplaisted commented Jan 18, 2017

rainersigwald commented Jan 18, 2017

Ziflin commented Feb 11, 2017 •

edited

Loading

mgwalm commented Feb 15, 2017

Ziflin commented Feb 15, 2017

dsplaisted commented Feb 15, 2017 •

edited

Loading

Ziflin commented Feb 15, 2017

dsplaisted commented Feb 15, 2017

Ziflin commented Feb 15, 2017

StingyJack commented Apr 25, 2017

darkurse commented Jun 21, 2017

rainersigwald commented Jun 21, 2017

DavidHollman commented Aug 22, 2018

rainersigwald commented Aug 22, 2018

StingyJack commented Aug 23, 2018

Rabadash8820 commented Sep 12, 2018

dasMulli commented Sep 12, 2018

DavidHollman commented Sep 12, 2018

StingyJack commented Sep 12, 2018

tamlin-mike commented Nov 5, 2019

trivalik commented May 17, 2021 •

edited

Loading

AndrueCope commented Oct 13, 2022

Charlieface commented Nov 23, 2023

ajtruckle commented Apr 11, 2024 •

edited

Loading

Standard build variables are not replaced in before/after build scripts. #677

Standard build variables are not replaced in before/after build scripts. #677

Comments

TheRealPiotrP commented Jan 18, 2017

Steps to reproduce

Expected behavior

Actual behavior

Environment data

srivatsn commented Jan 18, 2017

dsplaisted commented Jan 18, 2017

rainersigwald commented Jan 18, 2017

Ziflin commented Feb 11, 2017 • edited Loading

mgwalm commented Feb 15, 2017

Ziflin commented Feb 15, 2017

dsplaisted commented Feb 15, 2017 • edited Loading

Ziflin commented Feb 15, 2017

dsplaisted commented Feb 15, 2017

Ziflin commented Feb 15, 2017

StingyJack commented Apr 25, 2017

darkurse commented Jun 21, 2017

rainersigwald commented Jun 21, 2017

DavidHollman commented Aug 22, 2018

rainersigwald commented Aug 22, 2018

StingyJack commented Aug 23, 2018

Rabadash8820 commented Sep 12, 2018

dasMulli commented Sep 12, 2018

DavidHollman commented Sep 12, 2018

StingyJack commented Sep 12, 2018

tamlin-mike commented Nov 5, 2019

trivalik commented May 17, 2021 • edited Loading

AndrueCope commented Oct 13, 2022

Charlieface commented Nov 23, 2023

ajtruckle commented Apr 11, 2024 • edited Loading

Ziflin commented Feb 11, 2017 •

edited

Loading

dsplaisted commented Feb 15, 2017 •

edited

Loading

trivalik commented May 17, 2021 •

edited

Loading

ajtruckle commented Apr 11, 2024 •

edited

Loading