Dependency Could Not Be Resolved Error in Visual Studio 2015 RTM

Back to Listing

Dependency Could Not Be Resolved Error in Visual Studio 2015 RTM

22 Jul, 2015

Microsoft dropped the RTM (release to manufacturing) version of Visual Studio 2015 on Monday with great fanfare. I, like many other .NET developers, hopped on MSDN, downloaded their favorite flavor and installed it immediately. I was pretty happy to see that I could open my current project, compile and run without a single change to the solution or project files. There also appears to be a dramatic increase in performance of the text editors. Yay!

Yesterday, I decided to play around with the shipped bits of ASP.NET vNext. Obviously still in beta phase, but I should be able to whip up a little app to get my feet wet. A quick google search dropped me on a tutorial that I started working through.

When adding the Microsoft.AspNet.Diagnostics package to project.json, I started getting weird errors. It only seemed to happen when I was working in a new Empty Web project and attempting to add packages via the project.json or the NuGet Package Manager. I could create a new Web Application and the Diagnostics package was added with no issue.

Here are the symptoms:

Action: Create a new Empty web project and attempt to add Microsoft.AspNet.Diagnostics package to the project.json.

Result: Error List pane will display a build error "Dependency Microsoft.AspNet.Diagnostics >= 1.0.0-beta5 could not be resolved"

Action: In Powershell, navigate to the solution root and run a dnu restore. Note: You may need to run a dnvm use 1.0.0-beta5 first.

Result: A large stack dump with the following error: "System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required."

I am currently working at a large state institution and all of our traffic goes though a proxy. Apparently the pass through authentication is not being handled properly somewhere deep in the bowels of beta5. After doing much googling and issue report reading; I discovered a thread, which I have long since lost, that suggested a fix for the issue.

The solution was fairly simple. For each installed runtime in your .dnx folder, you need to add a dnx.exe.config to enable proxy settings. You should then be able to pull packages with no issues.

Here is a little powershell script that will automate the process for you.

$source = "";
Get-ChildItem "~\.dnx\runtimes" -Recurse -Force -Filter "dnx.exe" |  
    %{ $_.DirectoryName } |
    Get-Unique |
    ForEach { Invoke-WebRequest $source -OutFile "$_\dnx.exe.config" }
Share this story

Bobby Johnson

About Author

I am a passionate engineer with an interest in shipping quality software, building strong collaborative teams and continuous improvement of my skills, team and the product.

comments powered by Disqus
Back to top