Quantcast
Channel: WE MOVED to github.com/nuget. This site is not monitored!
Viewing all 7612 articles
Browse latest View live
↧

New Post: RestorePackages NuGet.targets

February 28, 2014, 2:56 pm
$
0
0
I'm getting something similar:
Warning 1 The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'RestorePackages' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'. List of possible elements expected: 'Property, AllowUnsafeBlocks, AppConfigForCompiler, ApplicationIcon, ApplicationRevision, ApplicationVersion, AppDesignerFolder, AspNetConfiguration, AssemblyKeyContainerName, AssemblyKeyProviderName, AssemblyName, AssemblyOriginatorKeyFile, AssemblyOriginatorKeyFileType, AssemblyOriginatorKeyMode, AssemblyType, AutoGenerateBindingRedirects, AutorunEnabled, BaseAddress, BootstrapperComponentsLocation, BootstrapperComponentsUrl, BootstrapperEnabled, CharacterSet, CheckForOverflowUnderflow, CLRSupport, UseDebugLibraries, CodePage, Configuration, ConfigurationName, ConfigurationOverrideFile, CreateDesktopShortcut, CreateWebPageOnPublish, CurrentSolutionConfigurationContents, DebugSecurityZoneURL, DebugSymbols, DebugType, DefaultClientScript, DefaultHTMLPageLayout, DefaultTargetSchema, DefineConstants, DefineDebug, DefineTrace, DelaySign, DisableLangXtns, DisallowUrlActivation, CodeAnalysisAdditionalOptions, CodeAnalysisApplyLogFileXsl, CodeAnalysisConsoleXsl, CodeAnalysisCulture, CodeAnalysisFailOnMissingRule.... C:\Users\User1\Documents\Visual Studio 2013\Projects\distro.nuget\NuGet.targets 7 10 .nuget

The internet doesn't seem to have an answer at the moment. I don't think it's hurting anything. Just ugly warnings.
↧
Search

Reopened Unassigned: NuGet should honor project reference without strongname [4048]

February 28, 2014, 3:15 pm
$
0
0
Since NuGet does a match on assembly identity, if there is a reference without strongname it ends up adding a new entry instead of updating it.

Repro:

1. In VS 2013 RTM create a One ASP Net MVC Project (Select Web API)
This will add the JSON.Net package 5.0.6 and we have the following reference in the csproj:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
2. Now update the JSON.Net package to 6.0.1
This adds a new reference in the csproj instead of updating the existing one. So you end up with 2 entries as follows:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

<Reference Include="Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\Newtonsoft.Json.6.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

Note, in the case when the original reference is as follows, the package upgrade does result in updating the entry correctly instead of adding a new one:
<Reference Include="Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

We should change the behavior to honor this entry as it is a valid one.
↧
↧

Edited Unassigned: NuGet should honor project reference without strongname [4048]

February 28, 2014, 3:16 pm
$
0
0
Since NuGet does a match on assembly identity, if there is a reference without strongname it ends up adding a new entry instead of updating it.

Repro:

1. In VS 2013 RTM create a One ASP Net MVC Project (Select Web API)
This will add the JSON.Net package 5.0.6 and we have the following reference in the csproj:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
2. Now update the JSON.Net package to 6.0.1
This adds a new reference in the csproj instead of updating the existing one. So you end up with 2 entries as follows:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

<Reference Include="Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\Newtonsoft.Json.6.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

Note, in the case when the original reference is as follows, the package upgrade does result in updating the entry correctly instead of adding a new one:
<Reference Include="Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

We should change the behavior to honor this entry as it is a valid one.
↧

Commented Unassigned: NuGet should honor project reference without strongname [4048]

February 28, 2014, 3:16 pm
$
0
0
Since NuGet does a match on assembly identity, if there is a reference without strongname it ends up adding a new entry instead of updating it.

Repro:

1. In VS 2013 RTM create a One ASP Net MVC Project (Select Web API)
This will add the JSON.Net package 5.0.6 and we have the following reference in the csproj:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
2. Now update the JSON.Net package to 6.0.1
This adds a new reference in the csproj instead of updating the existing one. So you end up with 2 entries as follows:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

<Reference Include="Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\Newtonsoft.Json.6.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

Note, in the case when the original reference is as follows, the package upgrade does result in updating the entry correctly instead of adding a new one:
<Reference Include="Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

We should change the behavior to honor this entry as it is a valid one.
Comments: Reopening to keep it as a tracking bug.
↧

Created Unassigned: NuGet.targets broken on Mono xbuild [4051]

February 28, 2014, 11:41 pm
$
0
0
<PropertyGroup>
<PackagesProjectConfig>packages.$(MSBuildProjectName.Replace(' ', '_')).config</PackagesProjectConfig>
</PropertyGroup>

The above element in NuGet.targets is not Mono xbuild friendly. Mono xbuild does not yet support property functions, so IMHO it should be changed to

<PropertyGroup>
<PackagesProjectConfig Condition=" '$(OS)' == 'Windows_NT'">packages.$(MSBuildProjectName.Replace(' ', '_')).config</PackagesProjectConfig>
<PackagesProjectConfig Condition=" '$(OS)' != 'Windows_NT'">packages.$(MSBuildProjectName).config</PackagesProjectConfig>
</PropertyGroup>

Of course it introduces another problem (that if the project name does contain spaces the PackagesProjectConfig evaluation can be wrong).

I also also fire a bug report to Mono,

https://bugzilla.xamarin.com/post_bug.cgi
↧
↧

Edited Unassigned: NuGet.targets broken on Mono xbuild [4051]

February 28, 2014, 11:41 pm
$
0
0
```
<PropertyGroup>
<PackagesProjectConfig>packages.$(MSBuildProjectName.Replace(' ', '_')).config</PackagesProjectConfig>
</PropertyGroup>
```

The above element in NuGet.targets is not Mono xbuild friendly. Mono xbuild does not yet support property functions, so IMHO it should be changed to

```
<PropertyGroup>
<PackagesProjectConfig Condition=" '$(OS)' == 'Windows_NT'">packages.$(MSBuildProjectName.Replace(' ', '_')).config</PackagesProjectConfig>
<PackagesProjectConfig Condition=" '$(OS)' != 'Windows_NT'">packages.$(MSBuildProjectName).config</PackagesProjectConfig>
</PropertyGroup>
```

Of course it introduces another problem (that if the project name does contain spaces the PackagesProjectConfig evaluation can be wrong).

I also also fire a bug report to Mono,

https://bugzilla.xamarin.com/post_bug.cgi
↧

Commented Issue: NuGet won't [x]build on Mono 3.x for Windows [2887]

February 28, 2014, 11:56 pm
$
0
0
Despite fixing up the lack of dmcs.bat with a new shim batch file to direct to "mcs -sdk:4 %*", there's something more fundamentally borked when building with xbuild on Mono. Apparently:

https://bugzilla.xamarin.com/show_bug.cgi?id=3055

Says:

"This is a known limitation that xbuild cannot handle <ItemGroup> and
<PropertyGroup> elements directly in Targets. One can use CreateItem and
CreateProperty items to work around this."
Comments: This issue has already been fixed on Mono side. So here this item can be closed as well.
↧

Commented Unassigned: Read credentials for private feeds from environment variables [3916]

March 1, 2014, 1:34 am
$
0
0
It would be nice if it was possible to store the credentials for private NuGet feeds in environment variables, instead of in the NuGet.config file. This would help when running NuGet package restore on a build server. Right now to do this you have two options:

1. Store all NuGet config info on each buildagent in the AppData folder. This is annoying because we want to avoid state on build agents.

2. Store a NuGet.config in the repository with a cleartext password. It can't be encrypted because the encryption is done at the user level so if I encrypt on my machine it will not work on the build server. Storing passwords in plain text in repositories is bad, so I definitely don't want to do that.

Most (all?) CI systems allow you to specify environment variables to pass to the build. The good ones also allow "secure" environment variables, so their values won't be logged anywhere. This is where I want to keep my credentials for private feeds, in the CI server configuration.

I have written the code for this myself, so a pull request is on the way. Maybe there are other better ways to do this, but a pull request with working code is at least a starting point to discuss this and figure out if it's useful.

Comments: Also starting TC8 there is a build feature to set credentials. Even easier :-)
↧
Search

Commented Unassigned: Read credentials for private feeds from environment variables [3916]

March 1, 2014, 8:04 am
$
0
0
It would be nice if it was possible to store the credentials for private NuGet feeds in environment variables, instead of in the NuGet.config file. This would help when running NuGet package restore on a build server. Right now to do this you have two options:

1. Store all NuGet config info on each buildagent in the AppData folder. This is annoying because we want to avoid state on build agents.

2. Store a NuGet.config in the repository with a cleartext password. It can't be encrypted because the encryption is done at the user level so if I encrypt on my machine it will not work on the build server. Storing passwords in plain text in repositories is bad, so I definitely don't want to do that.

Most (all?) CI systems allow you to specify environment variables to pass to the build. The good ones also allow "secure" environment variables, so their values won't be logged anywhere. This is where I want to keep my credentials for private feeds, in the CI server configuration.

I have written the code for this myself, so a pull request is on the way. Maybe there are other better ways to do this, but a pull request with working code is at least a starting point to discuss this and figure out if it's useful.

Comments: It's certainly possible to do with TeamCity, using your method of creating an empty config file and updating it before doing other things, or using TeamCity's built in credentials feature. I still think just reading the credentials from the environment and using them, without having to update config files, would be cleaner and a nicer way to do this. TeamCity's credentials feature only seems to work for me when I use their NuGet installer step, not if I just ran NuGet from my own script directly. Don't get me wrong, TeamCity is awesome, but reading credentials from environment variables would work in any CI system.
↧
↧

Commented Unassigned: Read credentials for private feeds from environment variables [3916]

March 1, 2014, 8:06 am
$
0
0
It would be nice if it was possible to store the credentials for private NuGet feeds in environment variables, instead of in the NuGet.config file. This would help when running NuGet package restore on a build server. Right now to do this you have two options:

1. Store all NuGet config info on each buildagent in the AppData folder. This is annoying because we want to avoid state on build agents.

2. Store a NuGet.config in the repository with a cleartext password. It can't be encrypted because the encryption is done at the user level so if I encrypt on my machine it will not work on the build server. Storing passwords in plain text in repositories is bad, so I definitely don't want to do that.

Most (all?) CI systems allow you to specify environment variables to pass to the build. The good ones also allow "secure" environment variables, so their values won't be logged anywhere. This is where I want to keep my credentials for private feeds, in the CI server configuration.

I have written the code for this myself, so a pull request is on the way. Maybe there are other better ways to do this, but a pull request with working code is at least a starting point to discuss this and figure out if it's useful.

Comments: Oh, and I did submit a pull request for this right after I created the issue, I forgot to link it from here. It's PR [5893](https://nuget.codeplex.com/SourceControl/network/forks/einaregilsson/NuGet/contribution/5893)
↧

New Post: NuGet Extend Update / Inclusion

March 1, 2014, 8:32 am
$
0
0
I've been working on some potential NuGet Extensions for a project and found that the NuGet Extend (addExtension command) package does not work properly with NuGet 2.8. Since I can't actually find where the package is maintained, I ended up using ILSpy to recreate the extension against 2.8. I also wrote a second command that gets the list of all of the available commands and what assembly they are contained in.

My question is this: Would there be any value in including these commands as another project similar to the CommandLine.ServerExtensions project? I currently have the changes in a fork, and can clean them up and submit a pull request if people are interested in them. I will probably need some guidance on the correct structure and formatting, etc...

Thoughts?
↧

Commented Unassigned: Schema version of Microsoft.AspNet.WebPages is incompatible with NuGet [4054]

March 4, 2014, 5:28 am
$
0
0
I'm getting an error whenever I try to load the NuGet extensions gallery from WebMatrix 3. Originally I had a problem when opening the Extensions panel in WebMatrix 3 with the NuGet extension itself. The Update function never worked, even after restarting WebMatrix 3. But I deleted the Extensions and Templates directories from both the local app data and Program x86 directories for WebMatrix 3, deleted all WebMatrix 3 cache directories, and then uninstalled and reinstalled WebMatrix 3. Now I get the error below when I try to open the NuGet packages gallery using the NuGet button in WebMatrix 3:

An error occurred.

The schema version of 'Microsoft.AspNet.WebPages' is incompatible with version 2.5.40416.9020 of NuGet. Please upgrade NuGet to the latest version from http://go.microsoft.com/fwlink/?LinkId=213942.

System.InvalidOperationException: The schema version of 'Microsoft.AspNet.WebPages' is incompatible with version 2.5.40416.9020 of NuGet. Please upgrade NuGet to the latest version from http://go.microsoft.com/fwlink/?LinkId=213942.
at NuGet.Manifest.CheckSchemaVersion(XDocument document)
at NuGet.Manifest.ReadFrom(Stream stream, IPropertyProvider propertyProvider, Boolean validateSchema)
at NuGet.LocalPackage.ReadManifest(Stream manifestStream)
at NuGet.OptimizedZipPackage.EnsureManifest()
at NuGet.OptimizedZipPackage..ctor(IFileSystem fileSystem, String packagePath)
at NuGet.LocalPackageRepository.OpenPackage(String path)
at NuGet.LocalPackageRepository.GetPackage(Func`2 openPackage, String path)
at NuGet.LocalPackageRepository.<>c__DisplayClass9.<FindPackage>b__5(String path)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
at NuGet.LocalPackageRepository.FindPackage(Func`2 openPackage, String packageId, SemanticVersion version)
at NuGet.LocalPackageRepository.FindPackage(String packageId, SemanticVersion version)
at NuGet.PackageRepositoryExtensions.FindPackage(IPackageRepository repository, String packageId, SemanticVersion version, IPackageConstraintProvider constraintProvider, Boolean allowPrereleaseVersions, Boolean allowUnlisted)
at NuGet.DataServicePackage.EnsurePackage(IPackageCacheRepository cacheRepository)
at NuGet.DataServicePackage.GetSupportedFrameworks()
at NuGet.PackageRepositoryExtensions.<>c__DisplayClass2a.<SupportsTargetFrameworks>b__29(FrameworkName t)
at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
at NuGet.PackageRepositoryExtensions.SupportsTargetFrameworks(IEnumerable`1 targetFramework, IPackage package)
at NuGet.PackageRepositoryExtensions.<>c__DisplayClass27.<GetUpdatesCore>b__23(IPackage candidate)
at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection)
at NuGet.PackageRepositoryExtensions.GetUpdatesCore(IPackageRepository repository, IEnumerable`1 packages, Boolean includePrerelease, Boolean includeAllVersions, IEnumerable`1 targetFramework, IEnumerable`1 versionConstraints)
at NuGet.DataServicePackageRepository.GetUpdates(IEnumerable`1 packages, Boolean includePrerelease, Boolean includeAllVersions, IEnumerable`1 targetFrameworks, IEnumerable`1 versionConstraints)
at NuGet.PackageRepositoryExtensions.GetUpdates(IPackageRepository repository, IEnumerable`1 packages, Boolean includePrerelease, Boolean includeAllVersions, IEnumerable`1 targetFrameworks, IEnumerable`1 versionConstraints)
at NuGet.WebMatrix.WebProjectManager.GetPackagesWithUpdates(String searchTerms, Boolean filterPreferredPackages)
at NuGet.WebMatrix.NuGetPackageManager.GetPackagesWithUpdates()
at NuGet.WebMatrix.NuGetModel.GetPackagesWithUpdates()
at NuGet.WebMatrix.FilterManager.GetUpdatePackages()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()

If I delete the AspNet.WebPages packages I then get a configuration error for the site itself since those files can not be found.

How can I fix this?
Comments: Thanks. Switching the source to NuGet got rid of the error. Unfortunately, when I run my WebMatrix site locally now, IIS Express isn't launched anymore so the web page can't load any of its referenced files. Do you know what I might have done during this process to cause this problem?
↧

Commented Unassigned: Schema version of Microsoft.AspNet.WebPages is incompatible with NuGet [4054]

March 4, 2014, 5:54 am
$
0
0
I'm getting an error whenever I try to load the NuGet extensions gallery from WebMatrix 3. Originally I had a problem when opening the Extensions panel in WebMatrix 3 with the NuGet extension itself. The Update function never worked, even after restarting WebMatrix 3. But I deleted the Extensions and Templates directories from both the local app data and Program x86 directories for WebMatrix 3, deleted all WebMatrix 3 cache directories, and then uninstalled and reinstalled WebMatrix 3. Now I get the error below when I try to open the NuGet packages gallery using the NuGet button in WebMatrix 3:

An error occurred.

The schema version of 'Microsoft.AspNet.WebPages' is incompatible with version 2.5.40416.9020 of NuGet. Please upgrade NuGet to the latest version from http://go.microsoft.com/fwlink/?LinkId=213942.

System.InvalidOperationException: The schema version of 'Microsoft.AspNet.WebPages' is incompatible with version 2.5.40416.9020 of NuGet. Please upgrade NuGet to the latest version from http://go.microsoft.com/fwlink/?LinkId=213942.
at NuGet.Manifest.CheckSchemaVersion(XDocument document)
at NuGet.Manifest.ReadFrom(Stream stream, IPropertyProvider propertyProvider, Boolean validateSchema)
at NuGet.LocalPackage.ReadManifest(Stream manifestStream)
at NuGet.OptimizedZipPackage.EnsureManifest()
at NuGet.OptimizedZipPackage..ctor(IFileSystem fileSystem, String packagePath)
at NuGet.LocalPackageRepository.OpenPackage(String path)
at NuGet.LocalPackageRepository.GetPackage(Func`2 openPackage, String path)
at NuGet.LocalPackageRepository.<>c__DisplayClass9.<FindPackage>b__5(String path)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
at NuGet.LocalPackageRepository.FindPackage(Func`2 openPackage, String packageId, SemanticVersion version)
at NuGet.LocalPackageRepository.FindPackage(String packageId, SemanticVersion version)
at NuGet.PackageRepositoryExtensions.FindPackage(IPackageRepository repository, String packageId, SemanticVersion version, IPackageConstraintProvider constraintProvider, Boolean allowPrereleaseVersions, Boolean allowUnlisted)
at NuGet.DataServicePackage.EnsurePackage(IPackageCacheRepository cacheRepository)
at NuGet.DataServicePackage.GetSupportedFrameworks()
at NuGet.PackageRepositoryExtensions.<>c__DisplayClass2a.<SupportsTargetFrameworks>b__29(FrameworkName t)
at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
at NuGet.PackageRepositoryExtensions.SupportsTargetFrameworks(IEnumerable`1 targetFramework, IPackage package)
at NuGet.PackageRepositoryExtensions.<>c__DisplayClass27.<GetUpdatesCore>b__23(IPackage candidate)
at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection)
at NuGet.PackageRepositoryExtensions.GetUpdatesCore(IPackageRepository repository, IEnumerable`1 packages, Boolean includePrerelease, Boolean includeAllVersions, IEnumerable`1 targetFramework, IEnumerable`1 versionConstraints)
at NuGet.DataServicePackageRepository.GetUpdates(IEnumerable`1 packages, Boolean includePrerelease, Boolean includeAllVersions, IEnumerable`1 targetFrameworks, IEnumerable`1 versionConstraints)
at NuGet.PackageRepositoryExtensions.GetUpdates(IPackageRepository repository, IEnumerable`1 packages, Boolean includePrerelease, Boolean includeAllVersions, IEnumerable`1 targetFrameworks, IEnumerable`1 versionConstraints)
at NuGet.WebMatrix.WebProjectManager.GetPackagesWithUpdates(String searchTerms, Boolean filterPreferredPackages)
at NuGet.WebMatrix.NuGetPackageManager.GetPackagesWithUpdates()
at NuGet.WebMatrix.NuGetModel.GetPackagesWithUpdates()
at NuGet.WebMatrix.FilterManager.GetUpdatePackages()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()

If I delete the AspNet.WebPages packages I then get a configuration error for the site itself since those files can not be found.

How can I fix this?
Comments: Please ignore that last question. While trying to fix the problem earlier I deleted several files from the WebMatrix package dir, some of which were necessary. I have restored them and the project is fine. Thanks again.
↧
↧

Created Unassigned: Inconsistent repositoryPath config. [4056]

March 4, 2014, 6:00 am
$
0
0
We have been using a custom repository path. Our nuget.config has always looked like the following.

```
<configuration>
<repositoryPath>..\..\Source\packages</repositoryPath>
</configuration>
```

However the nuget documentation states that it should look like the following.

```
<configuration>
<config>
<add key="repositorypath" value="..\..\Source\packages" />
</config>
</configuration>
```

So, I change it to the latter, and my dev machine doesn’t honor this configuration when building in visual studio and puts packages in the default $(SolutionDir)\packages folder, but the build machine (TFS Build 2013) does put the packages in the correct ..\..\Source\packages folder. As far as I can tell, we’re using the same version of NuGet (2.8). Updating the configuration to look like the following and we get packages going to a consistent location.

```
<configuration>
<config>
<add key="repositorypath" value="..\..\Source\packages” />
</config>
<repositoryPath>..\..\Source\packages</repositoryPath>
</configuration>
```

Works on both machines; we get a green build checkmark, we don’t need to commit our packages to source control any longer.

↧

Commented Unassigned: Install-Package : Project unavailable - Visual Studio 2012 - Package Manager Console [3398]

March 4, 2014, 6:39 am
$
0
0
Intermittently but Frequently the NuGet Package Manager completely stops working in Visual Studio 2012.

If I try and install a package I get this error:

```
PM> install-package <package name>
Install-Package : Project unavailable.
At line:1 char:16
+ install-package <<<< <package name>
+ CategoryInfo : NotSpecified: (:) [Install-Package], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,NuGet.PowerShell.Commands.InstallPackageCommand

```

The drop down for the Default Project is blank.

The Package Manager GUI also breaks.

The problem is intermittent but happens frequently and the only solution is completely close Visual Studio and reopen it.
Comments: This has just happened to me (Visual Studio 2012). First time it has happened. I'm not sure what the cause was. Restarting VS fixed it.
↧
Search

Commented Unassigned: Push package fails and keeps retrying [4000]

March 4, 2014, 6:55 am
$
0
0
Pushing a package to a (local) server that uses Windows Authentication fails (used to work in version 2.7)

Using Fiddler it gave me the impression that nuget keeps on retrying to upload where as nuget 2.7 uploads perfectly fine and receives a 302 (found) and a 201(created) response.

__These are the requests message response headers for 2.7:__

GET /nuget/Test HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:40:40 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication

GET /nuget/Test HTTP/1.0

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 358
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Set-Cookie: inedopg_isadmin=file_not_found; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYG2...00=
Date: Fri, 31 Jan 2014 13:40:40 GMT
Connection: close


PUT /nuget/Test/ HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:40:40 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication


PUT /nuget/Test/ HTTP/1.0

HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 149
Content-Type: text/html; charset=utf-8
Location: /api/v2/package/Test
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Set-Cookie: inedopg_isadmin=file_not_found; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oY...6k=
Date: Fri, 31 Jan 2014 13:40:41 GMT
Connection: close


PUT /api/v2/package/Test HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:40:41 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication


PUT /api/v2/package/Test HTTP/1.0

HTTP/1.1 201 Created
Cache-Control: private
Content-Length: 0
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oY...MU=
Date: Fri, 31 Jan 2014 13:40:41 GMT
Connection: close

__For nuget 2.8:__

GET /nuget/Test HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:53:18 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication


GET /nuget/Test HTTP/1.0

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 358
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Set-Cookie: inedopg_isadmin=file_not_found; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYG...p8=
Date: Fri, 31 Jan 2014 13:53:18 GMT
Connection: close

And then repeats these two requests over and over again.

Comments: __IIS__ Authentication: Windows Authentication Enabled (Http 401 Challenge), others: off. Authorization: Allow All Users __Folder__ The ApplicationPool's Identity has read and write access.
↧

Commented Unassigned: Update package in TFS bound project : TFS14092 : The item has a pending delete which must be checked in first. [4037]

March 4, 2014, 7:07 am
$
0
0
It seems this error has been already fixed, but occurs again in the version 2.8.50126.400

happens with local and server workspace (VS2012 and VS2013 NuGet Package Manager)

for repro steps refer to : https://nuget.codeplex.com/workitem/1690
Comments: Hello danliu, attached you will find a ZIP file with a solution and two packages. in the solution there is no package already installed, just do the following steps: 1. INSTALL -> .\NugetTFSTest\NugetStore\TFSPendingDelete.1.0.0.nupkg 2. CHECKIN 3. UPDATE -> .\NugetTFSTest\NugetStore\TFSPendingDelete.2.0.0.nupkg 4. ERROR please let me know if you can reproduce the problem, thanks password of the zip file is 12345 we think the problem occurs if in a subfolder an old files is removed and a new one is added
↧
↧

Commented Unassigned: Push package fails and keeps retrying [4000]

March 4, 2014, 9:55 am
$
0
0
Pushing a package to a (local) server that uses Windows Authentication fails (used to work in version 2.7)

Using Fiddler it gave me the impression that nuget keeps on retrying to upload where as nuget 2.7 uploads perfectly fine and receives a 302 (found) and a 201(created) response.

__These are the requests message response headers for 2.7:__

GET /nuget/Test HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:40:40 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication

GET /nuget/Test HTTP/1.0

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 358
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Set-Cookie: inedopg_isadmin=file_not_found; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYG2...00=
Date: Fri, 31 Jan 2014 13:40:40 GMT
Connection: close


PUT /nuget/Test/ HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:40:40 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication


PUT /nuget/Test/ HTTP/1.0

HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 149
Content-Type: text/html; charset=utf-8
Location: /api/v2/package/Test
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Set-Cookie: inedopg_isadmin=file_not_found; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oY...6k=
Date: Fri, 31 Jan 2014 13:40:41 GMT
Connection: close


PUT /api/v2/package/Test HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:40:41 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication


PUT /api/v2/package/Test HTTP/1.0

HTTP/1.1 201 Created
Cache-Control: private
Content-Length: 0
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oY...MU=
Date: Fri, 31 Jan 2014 13:40:41 GMT
Connection: close

__For nuget 2.8:__

GET /nuget/Test HTTP/1.0

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Fri, 31 Jan 2014 13:53:18 GMT
Connection: close
Content-Length: 1293
Proxy-Support: Session-Based-Authentication


GET /nuget/Test HTTP/1.0

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 358
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-UA-Compatible: IE=edge
Set-Cookie: inedopg_isadmin=file_not_found; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYG...p8=
Date: Fri, 31 Jan 2014 13:53:18 GMT
Connection: close

And then repeats these two requests over and over again.

Comments: looks like this issue is the same as https://nuget.codeplex.com/workitem/4050.
↧

Commented Unassigned: Inconsistent repositoryPath config. [4056]

March 4, 2014, 10:11 am
$
0
0
We have been using a custom repository path. Our nuget.config has always looked like the following.

```
<configuration>
<repositoryPath>..\..\Source\packages</repositoryPath>
</configuration>
```

However the nuget documentation states that it should look like the following.

```
<configuration>
<config>
<add key="repositorypath" value="..\..\Source\packages" />
</config>
</configuration>
```

So, I change it to the latter, and my dev machine doesn’t honor this configuration when building in visual studio and puts packages in the default $(SolutionDir)\packages folder, but the build machine (TFS Build 2013) does put the packages in the correct ..\..\Source\packages folder. As far as I can tell, we’re using the same version of NuGet (2.8). Updating the configuration to look like the following and we get packages going to a consistent location.

```
<configuration>
<config>
<add key="repositorypath" value="..\..\Source\packages” />
</config>
<repositoryPath>..\..\Source\packages</repositoryPath>
</configuration>
```

Works on both machines; we get a green build checkmark, we don’t need to commit our packages to source control any longer.

Comments: just to confirm, on your dev machine, you've installed NuGet 2.8 VSIX, i.e. if you open Tools -> Extension and Manager, NuGet version is 2.8.50126.***?
↧

Commented Unassigned: Update package in TFS bound project : TFS14092 : The item has a pending delete which must be checked in first. [4037]

March 4, 2014, 10:14 am
$
0
0
It seems this error has been already fixed, but occurs again in the version 2.8.50126.400

happens with local and server workspace (VS2012 and VS2013 NuGet Package Manager)

for repro steps refer to : https://nuget.codeplex.com/workitem/1690
Comments: @ssaado. thanks for providing such details. Will try to repro it and let you know. Thanks.
↧
Viewing all 7612 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>