Assembly version changes for system.text.json and dependency injection

[Anipik]

• We can regress assembly version for ME.DI because we ship ref only in the transport package
• json change was missing the assembly version update for netfx

[ghost]

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• We can regress assembly version for ME.DI because we ship ref only in the transport package
• json change was missing the assembly version update

Author:	Anipik
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[ahsonkhan]

Is there a way to test this (even one-off/locally) to make sure other assembly version attributes aren't missing for some supported TFM?

[ericstj]

@ahsonkhan can you clarify what you meant here? NetFramework is the only place where we must change the version (due to GAC). In 5.0 we are avoiding version changes for any assembly that is also part of the shared framework (and compatible TFMs like netstandard) so that we can have servicable ref-packs.

[ahsonkhan]

NetFramework is the only place where we must change the version (due to GAC)

I understand this is needed for .netfx only. The question I was trying to ask is, how do we verify that this change is correct and that we are not missing other assemblies that would need a similar change?

json change was missing the assembly version update for netfx

For example, how did we detect this originally?

[ericstj]

@Anipik reviews the changes that are made in servicing to ensure that they have both packaging and assembly changes since this is something unique to servicing. This is part of the "decision" to service the assembly, you can think of it as the change that represents the decision to opt something into shipping. We're aware that representing this decision requires more changes than we'd like and are thinking of ways to streamline that. Ultimately there will always be some change like this that says: increment a version and ship. We'd like to make it much simpler so that it's literally just that and all the conditions and special cases are handled by the build instead of the developer.

[ericstj]

@Anipik we use the Microsoft.Extensions.DependencyInjection when building other libraries.

runtime/src/libraries/Microsoft.Extensions.Logging/src/Microsoft.Extensions.Logging.csproj

Line 20 in 8e8a367

<ProjectReference Include="$(LibrariesProjectRoot)Microsoft.Extensions.DependencyInjection\src\Microsoft.Extensions.DependencyInjection.csproj" />

runtime/src/libraries/Microsoft.Extensions.Hosting/src/Microsoft.Extensions.Hosting.csproj

Line 17 in 1d9e50c

<ProjectReference Include="$(LibrariesProjectRoot)Microsoft.Extensions.DependencyInjection\src\Microsoft.Extensions.DependencyInjection.csproj" />

I think that @ViktorHofer made it so that these will get the reference assembly. As such, we may still want to version these non-shipping reference assemblies on .NETFramework so that we get the exact match for P2P references and avoid some unnecessary bindingRedirects. I don't think we've actually shipped any packages yet in 5.0 servicing that would observe this, but moving forward it seems like we can be stricter in our policy around versioning.

[ViktorHofer]

I think that @ViktorHofer made it so that these will get the reference assembly.

Yes, P2Ping a source project will forward the reference assembly to RAR / the compiler.

[ericstj]

Yep, so we should fix this up so that the net461 reference assembly gets the version bump even though it doesn't ship. It's good to know that our rules can be simpler.

I think that makes our versioning rules as simple as.

Is the assembly in a package?

• Yes
  • Is the assembly also in any shared framework?
    • Yes: Version only the NETFramework configurations
    • No: Version all configurations
• No
  • Don't version

@Anipik do you agree?

[ViktorHofer]

In the yes branch, why not always only update the NETFramework configuration?

[Anipik]

@ericstj we are implementing the same policy currently. (Mentioned in the above comment)

[ericstj]

@ericstj we are implementing the same policy currently. (Mentioned in the above comment)

Good good. I think we still need to fix this up:

runtime/src/libraries/Microsoft.Extensions.DependencyInjection/ref/Microsoft.Extensions.DependencyInjection.csproj

Line 4 in 8e8a367

<AssemblyVersion>5.0.0.0</AssemblyVersion>

why not always only update the NETFramework configuration?

It's still desirable to version when we can and matches the reccomendations we give to the community. There are still side-by-side loading issues with components that don't use ALC's. It's definitely something we could consider if we think removing that case would simplify.