Add additional metadata to deps.json to support "framework wins over app"

[steveharter]

This is the SDK work to support the core-setup feature https://github.com/dotnet/core-setup/issues/3546

That core-setup issue adds new metadata to the framework's deps.json to help determine which assemblies are newer during file-based probing. This would need to be done by the SDK during build and\or publish. That metadata includes assembly version and file version, where assembly version is compared first and if equal, then file version is compared.

@nguerrera

[nguerrera]

cc @ericstj @dsplaisted @eerhardt

I'm not sure we need any changes to conflict resolution as it already assumes greatest version wins. Or am I misunderstanding something?

[steveharter]

@nguerrera I updated the above description to include additional information.

The host is responsible for determining the full path of each assembly, and passing that to the CLR, so it needs to gather that information. Since the app and each framework can contain a copy of a given assembly (and servicing location and the store, but that's not important here), some sort of conflict resolution needs to occur.

Determining which copy of a given assembly wins is a two-step process:

1. Select all the framework(s) based on roll-forward, etc
2. Based on the app's and each framework's deps.json file, go through each assembly and probe each framework\app directory to determine if the assembly exists. If so, use that unless the assembly exists in more than one location\framework, then apply rules to help determine which one wins. For 2.0, the higher layer wins (app is highest layer) and no version information is considered.

[nguerrera]

@steveharter Thanks for the clarification.

I believe that once the deps.json schema is decided, the managed DepedencyModel API implemented in core-setup would need to be updated accordingly, and lastly the SDK would use DependencyModel appropriately. Is there a bug tracking the DependencyModel change?

[nguerrera]

Or perhaps the part where we'd write this is already dynamic/extensible enough to not require an API change?

[eerhardt]

Is there a bug tracking the DependencyModel change?

I'd think we can use the same core-setup feature bug - https://github.com/dotnet/core-setup/issues/3546. No need to open a new one, IMO.

Or perhaps the part where we'd write this is already dynamic/extensible enough to not require an API change?

No, I think it would require an API change. The DependencyModel isn't dynamic at all - there are properties for each entry in the .json file.

[steveharter]

@nguerrera the core-setup work on DependencyModel is now in, so this issue is now unblocked and the work to add the assemblyVersion and fileVersion can now occur during build\publish

[livarcocc]

@dsplaisted this is the bug I talked to you about. Please give it priority.

[dsplaisted]

@steveharter What are the new APIs in DependencyModel to take advantage of here, and what version of the DependencyModel package do they show up in?

[eerhardt]

@dsplaisted - see the new APIs added in dotnet/core-setup#3704.

They show up in any of the past 2 weeks builds of 2.1.0-preview2- or higher. For example, they are in 2.1.0-preview2-26306-03.

[nguerrera]

Is the plan still to write this only on publish in order to not sacrifice inner loop perf?