Macros $(DevEnvDir), $(SolutionFileName), $(SolutionPath), $(SolutionDir), $(SolutionName), $(SolutionExt) are not defined during publish. Worked fine during build
原文链接：https://github.com/dotnet/project-system/issues/2983
Tested on MS VS 2017 Community 2017, version 15.4.4, MS .NET Framework 4.7.02046.
A part of the code in .csproj:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.3" />
</ItemGroup>
There are targets with events executed after targets: BeforePublish, AfterPublish and used macros are not defined during publish.
<Target Name="BeforePublishEvents" AfterTargets="BeforePublish">
<Exec Command="echo Target: BeforePublishEvents executed AfterTarget: BeforePublish" />
<Exec Command="echo TargetDir: $(TargetDir)" />
<Exec Command="echo ProjectDir: $(ProjectDir)" />
<Exec Command="echo DevEnvDir: $(DevEnvDir)" />
<Exec Command="echo SolutionFileName: $(SolutionFileName)" />
<Exec Command="echo SolutionPath: $(SolutionPath)" />
<Exec Command="echo SolutionDir: $(SolutionDir)" />
<Exec Command="echo SolutionName: $(SolutionName)" />
<Exec Command="echo SolutionExt: $(SolutionExt)" />
</Target>
<Target Name="AfterPublishEvents" AfterTargets="AfterPublish">
<Exec Command="echo Target: AfterPublishEvents executed AfterTarget: AfterPublish" />
<Exec Command="echo TargetDir: $(TargetDir)" />
<Exec Command="echo ProjectDir: $(ProjectDir)" />
<Exec Command="echo DevEnvDir: $(DevEnvDir)" />
<Exec Command="echo SolutionFileName: $(SolutionFileName)" />
<Exec Command="echo SolutionPath: $(SolutionPath)" />
<Exec Command="echo SolutionDir: $(SolutionDir)" />
<Exec Command="echo SolutionName: $(SolutionName)" />
<Exec Command="echo SolutionExt: $(SolutionExt)" />
</Target>
On a publish output are undefined macros:
(SolutionFileName),
(SolutionDir),
(SolutionExt). These macros are undefined only while publish is executed. These macros are defined and work fine while a build is executed and in .csproj are targets with an option AfterTarget and targets BeforeBuild, PreBuildEvent, PostBuildEvent, AfterBuild.
Other targets like
(ProjectPath), $(ProjectName) are defined and work fine in publish and build. Isn't macros be defined during publish as during build?
Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
1>------ Build started: Project: TradingCore, Configuration: Release Any CPU ------
1>TradingCore -> D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0\TradingCore.dll
2>------ Publish started: Project: TradingCore, Configuration: Release Any CPU ------
Connecting to D:\Projects!Publish\Trading\Production\Release\TradingCore...
echo Target: BeforePublishEvents executed AfterTarget: BeforePublish
Target: BeforePublishEvents executed AfterTarget: BeforePublish
echo TargetDir: D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0
TargetDir: D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0
echo ProjectDir: D:\Projects\Trading\TradingCore
ProjectDir: D:\Projects\Trading\TradingCore
echo DevEnvDir: Undefined
DevEnvDir: Undefined
echo SolutionFileName: Undefined
SolutionFileName: Undefined
echo SolutionPath: Undefined
SolutionPath: Undefined
echo SolutionDir: Undefined
SolutionDir: Undefined
echo SolutionName: Undefined
SolutionName: Undefined
echo SolutionExt: Undefined
SolutionExt: Undefined
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Roslyn\csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702,1705,1701,1702,2008 /nostdlib+ /errorreport:prompt /warn:4 /define:TRACE;RELEASE;NETCOREAPP2_0 /errorendlocation /preferreduilang:en-US /reference:C:\Users\st....\AppData\Local\Temp.NETCoreApp,Version=v2.0.AssemblyAttributes.cs" obj\Release\netcoreapp2.0\TradingCore.AssemblyInfo.cs /warnaserror+:NU1605
TradingCore -> D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0\TradingCore.dll
"dotnet" exec --runtimeconfig "D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0\TradingCore.runtimeconfig.json" --depsfile "D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0\TradingCore.deps.json" "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.1\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.dll" @"obj\Release\netcoreapp2.0\microsoft.aspnetcore.mvc.razor.viewcompilation.rsp"
TradingCore -> D:\Projects\Trading\TradingCore\obj\Release\netcoreapp2.0\PubTmp\Out
echo Target: AfterPublishEvents executed AfterTarget: AfterPublish
Target: AfterPublishEvents executed AfterTarget: AfterPublish
echo TargetDir: D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0
TargetDir: D:\Projects\Trading\TradingCore\bin\Release\netcoreapp2.0
echo ProjectDir: D:\Projects\Trading\TradingCore
ProjectDir: D:\Projects\Trading\TradingCore
echo DevEnvDir: Undefined
DevEnvDir: Undefined
echo SolutionFileName: Undefined
SolutionFileName: Undefined
echo SolutionPath: Undefined
SolutionPath: Undefined
echo SolutionDir: Undefined
SolutionDir: Undefined
echo SolutionName: Undefined
SolutionName: Undefined
echo SolutionExt: Undefined
SolutionExt: Undefined
Web App was published successfully file:///D:/Projects/!Publish/Trading/Production/Release/TradingCore
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========
kirsan31, zahirtezcan-bugs, okumura-pico, and LeadManPL reacted with thumbs up emoji
@Pilchie
Member
Pilchie commented on Nov 28, 2017
@livarcocc - is this also an SDK issue? In general, I don't think these are reliably set in command line builds anyway, so it's probably best not to depend on them...
@livarcocc
livarcocc commented on Nov 28, 2017
The SDK does not set these properties. It is set somewhere else I believe.
@nguerrera can you check?
@Pilchie
Member
Pilchie commented on Dec 5, 2017
@stachu99 my guess is that this is related to #2982. In the case where they are undefined, it's because they are being launched by the dependency from "dotnet publish" to build, but outside of the IDE, these variables are not set.
@nguerrera
Contributor
nguerrera commented on Dec 5, 2017
cc @mlorbetske A publish initiated from VS should have the same properties as a build initiated by VS. I have seen that publish does not do this for SolutionDir and it actually triggers different behavior in the SDK resolver. If that's what's happening here, I think the VS code that kicks of publish should be changed to match how VS kicks off build.
@mlorbetske
mlorbetske commented on Dec 5, 2017
@vijayrkn
@Pilchie Pilchie added the Area-New-Project-System label on Jan 4, 2018
@Pilchie Pilchie added this to the Unknown milestone on Jan 4, 2018
@jjmew jjmew added Triage-Approved Reviewed and prioritizedand removed Triage-Approved Reviewed and prioritizedlabels on Jan 15, 2019
@davkean davkean removed the Project-System-CPS label on Jul 18, 2019
@dustinlacewell
dustinlacewell commented on Aug 12, 2019
What's going on with this issue...?
@nguerrera
Contributor
nguerrera commented on Aug 12, 2019
Ping, @vijayrkn This seems to be an issue with Publish in VS not setting the same properties on build as a regular build.
@vijayrkn
Contributor
vijayrkn commented on Aug 13, 2019
We do pass all the properties that we get from the project system during publish. I see that this issue was created an year before. Does this still happen?
@dustinlacewell
dustinlacewell commented on Aug 13, 2019 •
You definitely don't get things like $(SolutionDir) when doing dotnet build or dotnet publish in my experience. It would be super great if dotnet and Visual Studio were unified.
@nguerrera
Contributor
nguerrera commented on Aug 14, 2019
You should get $(SolutionDir) and the like on the command line if you are building a .sln, but not if you are building an individual project. Projects don't know what solution they are in and they could be in more than one so there's no real way to make that just work if you are operating on a single project on the command line.
