Skip to content

Conversation

@jpobst
Copy link
Contributor

@jpobst jpobst commented Jun 2, 2020

There is an issue with the new NuGet in that the lib/netcoreapp3.1 directory contains both SgmlReader.exe and SgmlReaderDll.dll and the netcoreapp3.1 version of param-name-importer tries to take the .exe.

Worked around this by using the <PackageReference> to download the NuGet but not reference any assembly. Then we add a <Reference> to the correct .dll and use it. (We use netstandard2.0 because both frameworks can use it, netcoreapp3.1 shouldn't even exist in the package.)

Additionally added a net4* Condition to the reference to System.IO.Compression to fix this warning:

Warning MSB3243: No way to resolve conflict between "System.IO.Compression, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "System.IO.Compression". Choosing "System.IO.Compression, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" arbitrarily.

The reference only appears to be needed on net472, not netcoreapp3.1.

@jpobst jpobst requested a review from jonpryor June 3, 2020 20:46
<!-- Not sure why needed, but only System.IO.Compression.FileSystem.dll is
included by default, and ZipArchive is type forwarded to System.IO.Compression -->
<Reference Include="System.IO.Compression" />
<Reference Include="System.IO.Compression" Condition="'$(TargetFramework)' == 'net472'" />
Copy link
Contributor

Choose a reason for hiding this comment

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

I half wonder if this shouldn't instead be $(TargetFramework.StartsWith('net4')), to "reasonably" support .NET Framework 4.8…

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed!

<!-- This package erroneously contains /netcoreapp3.1/SgmlReader.exe and /netcoreapp3.1/SgmlReaderDll.dll.
We are going to use a package reference to download the nuget, and a regular reference to actually
reference the correct assembly. -->
<PackageReference Include="Microsoft.Xml.SgmlReader" Version="1.8.16" ExcludeAssets="Compile" GeneratePathProperty="true" />
Copy link
Contributor

Choose a reason for hiding this comment

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

Does @(PackageReference) supports %(ReferenceOutputAssembly) metadata, e.g.

<PackageReference Include="Microsoft.Xml.SgmlReader" Version="1.8.16" ExcludeAssets="Compile" GeneratePathProperty="true" ReferenceOutputAssembly="false" />

If it does, that might make it clearer that the @(PackageReference) is present only for download purposes, and not for csc /reference purposes.

Copy link
Contributor Author

@jpobst jpobst Jun 4, 2020

Choose a reason for hiding this comment

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

I think %(ReferenceOutputAssembly) is only supported on @(ProjectReference). NuGet packages have no concept of output assemblies, they're just a zip of files in magic directories. The ExcludeAssets="Compile" is what is telling MSBuild not to use the contents for csc.

reference the correct assembly. -->
<PackageReference Include="Microsoft.Xml.SgmlReader" Version="1.8.16" ExcludeAssets="Compile" GeneratePathProperty="true" />
<Reference Include="SgmlReader">
<HintPath>$(PkgMicrosoft_Xml_SgmlReader)\lib\netstandard2.0\SgmlReaderDll.dll</HintPath>
Copy link
Contributor

Choose a reason for hiding this comment

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

Where does $(PkgMicrosoft_Xml_SgmlReader) come from? Is this a "NuGet-ism"? I don't see anything with this string in the current NuGet package that's used (the one prior to this PR).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It comes from GeneratePathProperty="true". This tells MSBuild/NuGet to create a magic property containing the path where it put the package. Without this we can't know where the package is, as the packages folder can be moved in NuGet.config.

@jonpryor jonpryor merged commit b136ac9 into master Jun 8, 2020
@jonpryor jonpryor deleted the sgml-nuget branch June 8, 2020 19:40
@jpobst jpobst added this to the 10.5 (16.8 / 8.8) milestone Jun 15, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Apr 13, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants