Updating search path in global.json won't invalidate lock in case where a package reference can change to a project reference.

[PradeepKadubandi]

I showed Troy the issue.

When we send 'RefreshDependencies' message to DTH, we are not getting the dependency message back. This is the log from DTH events:

Information: [ProcessingQueue]: OnReceive((19dd91876b82443881b571787736a990, RefreshDependencies, 1) -> null)
Information: [ApplicationContext]: Begin draining inbox.
Information: [ApplicationContext]: Received RefreshDependencies
Information: [ApplicationContext]: Finish draining inbox.
Information: [ApplicationHostContext] Using Lock File Target: DNX,Version=v4.5.1/
Information: [ApplicationHostContext] Using Lock File Target: DNX,Version=v4.5.1/
Information: [ApplicationHostContext] Using Lock File Target: DNX,Version=v4.5.1/win7-x86
Information: [LibraryExporter]: Resolving references for 'WebApplication1' 
Information: [LibraryExporter]: Resolved 137 references for 'WebApplication1' in 1ms
Information: [ApplicationHostContext] Using Lock File Target: DNXCore,Version=v5.0/
Information: [ApplicationHostContext] Using Lock File Target: DNXCore,Version=v5.0/
Information: [ApplicationHostContext] Using Lock File Target: DNX,Version=v4.5.1/win7-x86
Information: [LibraryExporter]: Resolving references for 'WebApplication1' 
Information: [LibraryExporter]: Resolved 182 references for 'WebApplication1' in 2ms
Information: [ApplicationContext]: OnTransmit(ProjectInformation)
Information: [ProcessingQueue]: Send((19dd91876b82443881b571787736a990, ProjectInformation, 1) -> {
  "Name": "WebApplication1",
  "Frameworks": [
    {
      "FrameworkName": "DNX,Version=v4.5.1",
      "FriendlyName": "DNX 4.5.1",
      "ShortName": "dnx451",
      "RedistListPath": "C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.5.1\\RedistList\\FrameworkList.xml"
    },
    {
      "FrameworkName": "DNXCore,Version=v5.0",
      "FriendlyName": "DNX Core 5.0",
      "ShortName": "dnxcore50",
      "RedistListPath": null
    }
  ],
  "Configurations": [
    "Debug",
    "Release"
  ],
  "Commands": {
    "web": "Microsoft.AspNet.Hosting --config hosting.ini",
    "ef": "EntityFramework.Commands",
    "gen": "Microsoft.Framework.CodeGeneration"
  },
  "ProjectSearchPaths": [
    "C:\\Users\\pradeek\\Documents\\Visual Studio 2015\\Projects\\WebApplication1\\src",
    "C:\\Users\\pradeek\\Documents\\Visual Studio 2015\\Projects\\WebApplication1\\test",
    "I:\\git\\aspnet\\scaffolding\\src"
  ],
  "GlobalJsonPath": "C:\\Users\\pradeek\\Documents\\Visual Studio 2015\\Projects\\WebApplication1\\global.json"
})
Information: [ApplicationContext]: SendDiagnostics, 6 diagnostics, 0 waiting for diagnostics.

[davidfowl]

Did dependencies change? /cc @anurse Could this be a caching bug? Do we still have the same cache dependencies as when we were caching the ApplicationHost context?

[troydai]

Dependencies doesn't change, just adds a search path in global.json. The expectation is that the project references will be sent back to VS can act. The scenario works for beta-6 as I just tried seconds ago. I'm trying this on beta8 now.

[troydai]

Yeah, it's a regression from beta7. I'll investigate after lunch.

[troydai]

@muratg @glennc This looks like a DTH related issue, I assign this to myself for now. Please advice otherwise.

[troydai]

/cc @davidfowl @PradeepKadubandi

After recent runtime refractory the dependency resolving now purely depends on the lock file. The lock file is not updated in this case, therefore updating global.json won't update the dependencies of projects.

There are a few solutions.

One is to make VS restore every project when search paths are changed in global.json. This solution doesn't require runtime change and also align with the usage of DNX at runtime. However, design time takes performance hit when global.json is updated. It is not idea for large solution like MVC.

The other idea is to adding communicate message between DTH and VS. Whenever search paths are updated VS asks DTH to advise if a restore is needed. Internally DTH can scan through the project.json and map the dependencies then comparing to the lock file. This solution requires change in DTH and also add new feature to DTH protocol.

The last solution is to partially walk back the runtime refractory. In addition to lock file, a list of projects in search paths is listed. For every dependencies read from the lock file a quick query can be made against the list so as to know if the lock file is invalid. This logic can be triggered for design time only.

[troydai]

Ping @davidfowl

[davidfowl]

We're going to need to force a restore in this case so that the lock files update

[troydai]

@PradeepKadubandi

[PradeepKadubandi]

Logged a tooling issue : https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems#_a=edit&id=144563&fullScreen=false

[troydai]

Thanks @PradeepKadubandi. I'll close this issue as it doesn't need work on runtime side.

[davidfowl]

I have some second thoughts about this.

[troydai]

Per discussion with @davidfowl, we decide to reopen this issue and explore a new solution.

We can log the search paths (from global.json) in lock file. As a result, we can invalidate the lock file when global.json is updated. It helps tooling mitigate the performance hit. And also make the console solution more reliable.

[troydai]

/cc @muratg @PradeepKadubandi

[troydai]

New solution:

1. At runtime, stop validating lock file, let it run as is.
2. Validating lock file at compile time and design time (DTH). In terms of the project paths scan the disk.

[troydai]

Fixed in 5066768