Bump AssemblyVersion for nestandard.dll to 2.1.0.0 #1047
Changes from 10 commits
2a86ab2
652fa70
8a2dad7
4a6c6c7
30ceb5f
aaf5d76
b5b2269
cff4621
47bb861
4f59964
44ddc12
399a7bc
b51ec87
4a078e2
a54c648
e51ac40
cca360f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,8 +1,16 @@ | ||
<?xml version="1.0" encoding="utf-8"?> | ||
<Project DefaultTargets="Build"> | ||
<PropertyGroup> | ||
<TargetFramework>net461</TargetFramework> | ||
<TargetFramework>netstandard2.1</TargetFramework> | ||
</PropertyGroup> | ||
|
||
<!-- Disable code paths that require project.assets.json files to be present or to be computed. --> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did you need these? They all look netcoreapp specific, I wouldn't expect them to be causing a problem for netstandard build. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes to disable the Target that tries to resolve stuff from
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, that's annoying. It looks like SDK does indeed try to do this for netstandard projects. What changed that caused that to start breaking? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess just the retargeting to ns2.1. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see we're doing this elsewhere: https://github.com/dotnet/standard/search?q=GenerateDependencyFile&unscoped_q=GenerateDependencyFile. Can we centralize it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please consider a followup PR to centralize these properties. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lol. One of my follow-up PRs would have been to bring back project restore so that we don't need these hacks. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even better 👍 |
||
<PropertyGroup> | ||
<GenerateDependencyFile>false</GenerateDependencyFile> | ||
<ComputeNETCoreBuildOutputFiles>false</ComputeNETCoreBuildOutputFiles> | ||
<GenerateRuntimeConfigurationFiles>false</GenerateRuntimeConfigurationFiles> | ||
</PropertyGroup> | ||
|
||
<Import Condition="Exists('..\Directory.Build.props')" Project="..\Directory.Build.props" /> | ||
|
||
<Target Name="MarkProjectReferencesAsNotPrivate" BeforeTargets="AssignProjectConfiguration"> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you need to set this? I would have expected that we would have disabled all the implicit package references in this repository (so it doesn't end up referencing what we are actually building).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SDK packages all implicitly reference NetStandard.Library/Microsoft.NETCore.App, if I don't set this we'll restore the default version & I won't have the path to find that package in my package cache. If I set it here, this project will restore the version that I want so I know where to find it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you consider DisableImplicitFrameworkReferences?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I see we already use that in some projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I figured it was easier to use the implicit reference & just give it a specific version to restore, rather than disabling the reference to
NetStandard.Library
then adding a manual reference to it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, are you sure we'll restore one of those projects that references it? The other places where we're working around missing assets file make me think we may not be. If that's the case maybe we can just add an explicit reference somewhere that we're sure will be restored.