Microsoft.Win32.Registry.dll version in ref doesn't match the one in nupkg

[tloo]

When I build Microsoft.Win32.Registry, it will generate "4.0.1.0". But when I build the package, it is using "4.0.0.0", which doesn't have my changes!
Could someone help to explain how does it happen? And where does "4.0.0.0" come from?

[karelz]

There can be multiple versions of the assembly in the NuGet package. Can you check all of them and confirm that none of the DLLs in your built package is the one with your changes?

[tloo]

Only the one in Microsoft.Win32.Registry.4.3.0\runtimes\win\lib\netstandard1.3 contains my changes, the others doesn't.
Here is the list inside the nupkg.
C:\Users\ttian\Desktop\Microsoft.Win32.Registry.4.3.0>dir /s /b Microsoft.Win32.Registry.dll
C:\Users\ttian\Desktop\Microsoft.Win32.Registry.4.3.0\lib\net46\Microsoft.Win32.Registry.dll
C:\Users\ttian\Desktop\Microsoft.Win32.Registry.4.3.0\ref\net46\Microsoft.Win32.Registry.dll
C:\Users\ttian\Desktop\Microsoft.Win32.Registry.4.3.0\ref\netstandard1.3\Microsoft.Win32.Registry.dll
C:\Users\ttian\Desktop\Microsoft.Win32.Registry.4.3.0\runtimes\unix\lib\netstandard1.3\Microsoft.Win32.Registry.dll
C:\Users\ttian\Desktop\Microsoft.Win32.Registry.4.3.0\runtimes\win\lib\net46\Microsoft.Win32.Registry.dll
C:\Users\ttian\Desktop\Microsoft.Win32.Registry.4.3.0\runtimes\win\lib\netstandard1.3\Microsoft.Win32.Registry.dll

[karelz]

What kind of project do you intend to use the NuGet package in? Desktop app? .NET Core app? .NET Standard library?
@sepidehms @ericstj do you know how the NuGet resolution works in this case?

[ericstj]

If you're adding API to the ref for all platforms you need to version it. If you're adding API only for NETCoreapp then you need to cross compile it.

The reason we don't use your changes is that we harvest the last shipped assembly for the ref if the API version (minor) has not changed.

[tloo]

.NET Core app.

[ericstj]

Ok, in that case you can follow the pattern like this:
https://github.com/dotnet/corefx/tree/master/src/System.Text.RegularExpressions/ref

You cross-compile the reference for netcoreapp and only expose your new API there. Folks will only be able to see your new API when targeting netcoreapp, not netstandard, which is expected.

/cc @joperezr who's been helping folks do something similar for ZipFile.

[karelz]

@tloo are you adding new APIs or just making fixes?
If you're adding new APIs, please be aware that the API surface has to be first approved (see API review process).

[tloo]

@ericstj I don't quite understand, I added one new API in those two files:
corefx/src/Microsoft.Win32.Registry/ref/Microsoft.Win32.Registry.cs
corefx/src/Microsoft.Win32.Registry/src/Microsoft/Win32/RegistryKey.cs
How could I expose it to my app?

@karelz We don't have any plan to commit the changes, that's used only for our project.

[ericstj]

TL;DR: add <Preserve>true</Preserve> to the ref projectreference in the pkgproj like this

A change such as the following is the correct thing to do if you plan on committing this. That makes the API specific to NETCoreApp.
dotnet/corefx@8b0f3fa#diff-777cae68d95c24aeedbe5681d5dc446d

If you don't care about committing it, you could do a simpler fix which would be preserve your updated reference, by adding <Preserve>true</Preserve> to the ref projectreference in the pkgproj.
dotnet/corefx@c8ea1c3#diff-dc39c125d06ebb6f4320b7b5aca88a5cR13

The reason that can't be committed is because it will fail API compat for desktop since .NET desktop may not have the API you're adding to the netstandard reference assembly.

Another option would be to increment the minor version of all assemblies by updating Microsoft.Win32.Registry\dir.props. This is typically what we do for API additions and signals to the tools that the ref is significantly different (new API) and should be included. This has the same problem as above since you're new API doesn't exist in desktop.

[tloo]

@ericstj Great! Adding <Preserve>true</Preserve> works! Thanks a lot! This has confused me for one week!
But I still have two questions:

1. How could I add custom label in nupkg, for example:
   Microsoft.Win32.Registry.4.3.0-aa-0.nupkg
   It seems change <PreReleaseLabel>aa</PreReleaseLabel> in Packaging.props doesn't help.
2. I'm using this command
   dotnet restore --packages .\packages
   to save the packages to my local folder instead of the default one (C:\Users\ttian\.nuget\packages).
   But how could I build and publish with my local packages?
   It seems that the build and publish command doesn't have --packages option.

[sepidehkh]

@tloo Is your question still valid?

[ericstj]

I'll try to answer these questions.

1. Changing PreReleaseLabel is the right thing to do. Let me know if this still doesn't work.
2. See this issue for the workaround: https://github.com/dotnet/cli/issues/2712.

Additionally, you'll want to make sure that you use build -allConfigurations in the latest CoreFx in order to build the packages.

[sepidehkh]

Thanks @ericstj!

[sepidehkh]

Questions seem to be answered, so closing. @tloo please re-open otherwise.