Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force bindingRedirect for System.Resources.Extensions #39386

Merged
merged 1 commit into from
Jul 16, 2020
Merged

Force bindingRedirect for System.Resources.Extensions #39386

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions src/libraries/System.Resources.Extensions/src/System.Resources.Extensions.csproj
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,4 +37,30 @@
<Reference Include="mscorlib" />
<Reference Include="System" />
</ItemGroup>

<PropertyGroup>
<_packageTargetsFile>$(IntermediateOutputPath)$(AssemblyName).targets</_packageTargetsFile>
</PropertyGroup>

<Target Name="GeneratePackageTargetsFile"
Condition="'$(TargetFramework)' == 'net461'"
Inputs="$(MSBuildAllProjects)"
Outputs="$(_packageTargetsFile)"
BeforeTargets="GetFilesToPackage">
<PropertyGroup>
<_packageTargetsFileContent><![CDATA[<Project>
<!-- ResolveAssemblyReferences will never see the assembly reference embedded in the resources type,
force a binding redirect ourselves so that we'll always unify to the System.Resources.Extensions
version provided by this package -->
<ItemGroup>
<SuggestedBindingRedirects Include="$(AssemblyName), Culture=neutral, PublicKeyToken=$(PublicKeyToken)" MaxVersion="$(AssemblyVersion)" />
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to generate this file since it depends on AssemblyVersion. That way we don't need to "remember" to update another place when AssemblyVersion changes.

</ItemGroup>
</Project>
]]></_packageTargetsFileContent>
</PropertyGroup>
<WriteLinesToFile File="$(_packageTargetsFile)" Overwrite="true" Lines="$(_packageTargetsFileContent)" />
<ItemGroup>
<FilesToPackage Include="$(_packageTargetsFile)" TargetPath="build/$(TargetFramework)" TargetFramework="$(TargetFramework)" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: any reason why not to hardcode $(TargetFramework) to net461? I'm afraid of some future change that may change targetframeworks in the future and might make us package an extra targets file where we shouldn't. Plus, you are already hardcoding the net461 on the condition so it doesn't seem that bad to do it here too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually I try to minimally hardcode things. The condition hardcodes TFM once just as you would to condition items that only apply to a single TFM.

</ItemGroup>
</Target>
</Project>