VS2017 15.8.1
I am working on a project that targets netstandard2.0, net451 and net461. For local debugging purposes, in the project properties dialogs I enabled generate package on build and set Output Path to a centralized location which is also configured as a local NuGet repository.
When I build the project, only a netstandard2.0 folder is created in the Output Path. The net451 and net461 builds and the NuGet package are still created in the default bin folder. (I assume the package just picks up the last msbuild target.)
You can reproduce this by building the dev branch of this Serilog project. (You'll have to set the generate flag and output after cloning, we don't store those settings in the repo.) I'm pretty sure this is a relatively recent problem, I converted this to a multi-target project several months ago using the same centralized-package-folder setup and did not see this behavior.
I see the problem is that $(TargetFramework) is part of the condition in the csproj even though it can't be controlled through the UI.
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|netstandard2.0|AnyCPU'">
<OutputPath>C:\Source\_dev_nuget_packages\serilog-settings-configuration\</OutputPath>
</PropertyGroup>
At least I can work around this. I'm aware from other issues and threads that the project properties UI is recognized as badly needing an overhaul, so I guess this is just another item to track. (I couldn't find a similar report anywhere, except a vaguely related request to provide a separate NuGet output path, which I agree would be great to have.)
Tagging @cartermp, who has been taking a bit of a look at both the property page and multi-targeting experiences to think about what we could do better here.
Thanks for the report, this is definitely something to consider as you've said, @MV10. It sounds like there are two distinct things here:
(2) doesn't preclude (1) - though that's without me having an understanding of what it would take to adjust the system to enable (1).
I mentioned I didn't see this a few months ago on the same project. I think what happened was I set up the centralized local repo output path, _then_ I manually edited the csproj for multiple TFMs, so the PropertyGroup Condition was already there without the $TFM part. (Of course, that would be the preferred behavior -- I wouldn't want it changing manual alterations.)
I wish I had more time, in my head I've been imagining a VS extension with a designer-like side-by-side project XML view and a realtime-updated properties dialog... csproj capabilities have really exploded in the past couple years, it's close to impossible to do anything beyond the basics without getting into the XML now. Good problems to have, I guess.
Most helpful comment
Tagging @cartermp, who has been taking a bit of a look at both the property page and multi-targeting experiences to think about what we could do better here.