NuGet

Commented Issue: NuGet should not generate binding redirects for binaries that are in the current framework [3072]

dotnetjunky — Wed, 19 Jun 2013 22:56:27 GMT

We're hitting an issue with Microsoft.Bcl package where NuGet is adding a binding redirect for a binary that is considered part of the framework, this causes the application to crash because the binding redirect refers to assembly version that is not available at runtime.

@Repro:

1. Create a new Console Application targeting 4.5
2. Create a new Portable Library targeting .NET Framework 4.5, Silverlight 4, Windows Phone 7.5 and .NET for Windows Store apps
3. Add a reference to the portable library from the Console Application
4. Install the Microsoft.Bcl package (1.0.16-rc) to both projects

@Expected: No binding redirect for System.Runtime in the .NET Framework 4.5 project because a ___later version___ is part of the target framework (see C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\RedistList\FrameworkList.xml)
@Actual: Binding redirect

<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.5.11.0" newVersion="1.5.11.0" />
</dependentAssembly>

You can use the IVsFrameworkMultiTargeting to determine if a given assembly version is available as part of a given target framework.
Comments: Fixed in changeset b8d515f6341193b970d2a9d837e580e762d2eb71

Edited Issue: NuGet should not generate binding redirects for binaries that are in the current framework [3072]

dotnetjunky — Wed, 19 Jun 2013 22:56:27 GMT

Source code checked in, #dfdeaded66d6d1095df7eb7c75e307cede75ded6

dotnetjunky — Wed, 19 Jun 2013 22:55:52 GMT

Do not run test in Vs 2010

Source code checked in, #b8d515f6341193b970d2a9d837e580e762d2eb71

dotnetjunky — Wed, 19 Jun 2013 22:55:50 GMT

Do no add binding redirects for assemblies that are already part of the framework. Work items: 3072

Source code checked in, #eb89f05aa68095f50d69eebee283373e6d2365f6

feiling — Wed, 19 Jun 2013 22:36:43 GMT

Implement the restore command

Commented Unassigned: mono xbuild packages don't restore [3332]

knocte — Wed, 19 Jun 2013 22:16:12 GMT

Under nuget 2.5, using xbuild (Mono 3.0.6 OSX) doesn't restore packages because of an extra space found on line 54 in the NuGet.targets file:

<RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)" $(NonInteractiveSwitch) $(RequireConsentSwitch) -solutionDir "$(SolutionDir) " </RestoreCommand>

The extra space is found here "$(SolutionDir) ". By removing the extra space such that it looks like "$(SolutionDir)", the package build process works perfectly.

This is very easy to fix in any repositories where the NuGet.targets file is already committed, but would be overwritten when pointing to a newer release of NuGet.
Comments: @jonathansoliver: can you elaborate on the "crazy reason"? What happens when the space is not there in Windows? I also don't understand how the trailing space would be considered an extra directory in Linux/Mac.

Edited Issue: Undue circular dependency detected [2965]

dotnetjunky — Wed, 19 Jun 2013 21:40:11 GMT

Hello,
There is a bug in the way circular dependencies are computed. A fix for this is available [here](http://nuget.codeplex.com/SourceControl/network/forks/xaviernoelle/NuGet/contribution/3802) but I don't have the time to write tests as requested.

You will find attached a zip file containing three projects : Father, Son and User :
- The Father project depends on the Son project
- The User project depends on both the Father and Son projects

You just need to unzip the archive, modifiy the build.bat to replace "YOUR_DOTNET_VERSION" by...your .Net version, run it and see for yourself.

The catch here is that "Son" depends (on purpose) on an "Unknown" package. Inverting "Son" and "Father" in the packages.config file of the User project "solves" the problem.

The inner problem is in fact that when the circular dependency checker stumbles upon the "Unknown" package dependency (for "Son"), it returns from the method without marking the "Son" package as visited. Then, when dependencies are checked for the "Father" project, the "Son" package is still in a "processing" state (for no reason), which throws a circular dependency exception.

Thanks in advance !

Edited Issue: Undue circular dependency detected when developmentDependency="true" [3378]

dotnetjunky — Wed, 19 Jun 2013 20:35:42 GMT

NuGet 2.7.40601.9000

An incorrect circular dependency is detected when developmentDependency is set to true for one of the packages in the scenario described below.

Repro steps:
- Create a C# ASP.NET MVC 4 Project Basic on Visual Studio 2012.
- Go to packages.config and add attribute developmentDependency="true" for the package with id="jQuery" (_see 1.png_).
- Create a package from this project. A warning message appears (_see 2.png_).

In this message, elmah.corelibrary 1.2.2 is shown to be dependent on EntityFramework, which is not true, because it has no dependencies (_see 3.png_).

Expected: No circular dependency is detected and package is created (without dependency on jQuery).

New Post: Changing package id - best practise

dalager — Wed, 19 Jun 2013 17:51:26 GMT

Jeff,
That would leave me with two listed packages with the same name, which is not what I want, is it?
The first package only got about 20 installs, so its the early days yet, so I would consider a sacrifice in order to avoid a double listing.

New Post: Changing package id - best practise

dalager — Wed, 19 Jun 2013 17:51:26 GMT

New Post: Changing package id - best practise

dalager — Wed, 19 Jun 2013 17:51:26 GMT

New Post: Changing package id - best practise

JeffHandley — Wed, 19 Jun 2013 17:35:34 GMT

Note that you should actually leave the new (empty) version of the package as listed. That will allow the check for updates to the package to find the new version and "redirect" the consumer to the new package.

New Post: Changing package id - best practise

JeffHandley — Wed, 19 Jun 2013 17:35:34 GMT

New Post: Changing package id - best practise

JeffHandley — Wed, 19 Jun 2013 17:35:34 GMT

Commented Issue: The remote name could not be resolved: 'az320820.vo.msecnd.net' [2503]

JeffHandley — Wed, 19 Jun 2013 17:23:51 GMT

When I try to install any package clicking button "Install", a getting the error: "Operation Failed"
"The remote name could not be resolved: 'az320820.vo.msecnd.net'" on red
Comments: Whenever this issue occurs, it's a DNS failure meaning your computer is unable to resolve the host name to an IP address. DNS resolution can occur at many different hops between you and the authoritative DNS server for the host. When this issue occurs, you can open a command window and run the command "nslookup az320820.vo.msecnd.net" to see what the results are. This command will run the DNS lookup for the host and return the IP address. If this fails, please capture the response and post it here. This information can help us determine if the DNS issue is closer to your ISP or closer to the authoritative DNS server for the domain. Thanks!

Edited Issue: nuget installing packages to /net40 folder instead of /sl4 folder for default Windows Phone 7 XNA template [2276]

dotnetjunky — Wed, 19 Jun 2013 16:57:33 GMT

What could be calling nuget to install packages such as JSON.NET to /net40 folder like the following?

{project folder}\packages\Newtonsoft.Json.4.5.6\lib\net40\Newtonsoft.Json.dll

This is causing some of my libraries to break? Is there anyway to make it install to the Silverlight\v4.0\ folder?

Created Unassigned: It should be clearer that the NuGet.exe on releases page is the command line util [3420]

wwahammy — Wed, 19 Jun 2013 16:28:07 GMT

I just encountered someone wanting to use NuGet on Mono. They were building NuGet.exe from source because they thought that the NuGet.exe on the releases page was some sort of installer for NuGet. Considering that usually release downloads are usually installation tools (like the .VSIX about it), this is a reasonable confusion.

Is there some way of indicating to people, preferably on the download page, that NuGet.exe is actually the command line utility, not an installation package?

Commented Issue: Clean cache automatically when package corrupted [3176]

yanglee — Wed, 19 Jun 2013 15:16:31 GMT

Today when I tried to install several nuget packages (Fody addins), I got error "Received an unexpected EOF or 0 bytes from the transport stream". Since I never experienced this error with other packages, I thought that was Fody's issue, so I raised a bug with Fody: [https://github.com/Fody/Fody/issues/55](https://github.com/Fody/Fody/issues/55)

At the end, the issue was fixed by deleting nuget's cache folder and manually downloading the package from web browser and coping it to the cache folder.

nuget should handle this issue automatically, or at least display a more useful error message like "Oops, something went wrong, we might have some corrupted packages in the cache folder. Please try..."

Comments: @feiling, sorry the corrupted packages were deleted. I haven't experienced this issue again since my previous post. I will attach a package if I see it again.

Commented Issue: The remote name could not be resolved: 'az320820.vo.msecnd.net' [2503]

Oceanswave — Wed, 19 Jun 2013 13:22:19 GMT

Commented Issue: The remote name could not be resolved: 'az320820.vo.msecnd.net' [2503]

Oceanswave — Wed, 19 Jun 2013 13:20:55 GMT

When I try to install any package clicking button "Install", a getting the error: "Operation Failed"
"The remote name could not be resolved: 'az320820.vo.msecnd.net'" on red
Comments: Just received this today from an automated build on the TFS Build Service: C:\a\src\.nuget\nuget.targets (80): The remote name could not be resolved: 'az320820.vo.msecnd.net' C:\a\src\.nuget\nuget.targets (80): The command ""C:\a\src\.nuget\nuget.exe" install "C:\a\src\Server\------------------\packages.config" -source "" -RequireConsent -o "C:\a\src\packages"" exited with code 1.