I've created a brand new solution and project in VS2017 RC and for some reason I can't use the latest version of the NETStandard.Library package.
There's no code in the project and it's the first project in the solution.
When in the NuGet package manager it's listed in the dropdown, but marked as blocked by project.
Any ideas?
You need to execute the command in Package manager console for your project
Install-Package NETStandard.Library
The NETStandard.Library package is no longer meant to be upgradable through the package management UI. The "SDK" component of the project emits this reference automatically and marked read-only.
This behaviour can be overridden through a property in the csproj file:
<NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
If you delete a line like this from your csproj file, you'll get the newest version that VS or the CLI knows about.
This property is usually added when migrating from project.json to csproj. In this case, you can safely remove it.
Related
I upgraded my azure function sdk from 1.0.14 to 1.0.28 and I get this build error:
The ExtensionsMetadataGenerator package was not imported correctly.
I can't find any documentation or ways to resolve it.
According to the 1.0.28 function sdk released several day ago, it may have some bugs in it.
Workaround:
Manually adding the
Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator nuget package to your project and it will work well.
I got this error when starting with the Visual Studio Function App template which uses Microsoft.NET.Sdk.Functions 1.0.31 and is a .NET Core 2.0 App.
Nuget Package Manager wants to update the Microsoft.NET.Sdk.Functions package to version 3.0.2 which it tries to do but the app is still .NET Core 2 and you get the error:
The ExtensionsMetadataGenerator package was not imported correctly.
To resolve this update the application to .NET Core 3:
Make sure you update your Microsoft.NET.Sdk.Functions NuGet package to the newest version that supports your app's version of .NET.
For example, I have a web app running .NET 2.1, I had to rollback the NuGet version to 1.0.36, and the next version (3.0) only worked on .NET 3 and up. After doing this, Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator NuGet was not needed at all and all my errors were gone.
I am working with microsoft.net.sdk.functions 1.0.38 and see the same message but in my case it is a build warning and not an error.
I installed the suggested NuGet package with the version required. However, I then received 3 warnings:
The ExtensionsMetadataGenerator package was not imported correctly. Are you missing 'C:\Users\me\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.2.0\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets' or 'C:\Users\me\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.2.0\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.props'? "C:\Users\me\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.2.0\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.props" cannot be imported again. It was already imported at "C:\Users\me\.nuget\packages\microsoft.net.sdk.functions\1.0.38\build\Microsoft.NET.Sdk.Functions.props (56,3)". This is most likely a build authoring error. This subsequent import will be ignored. [D:\myproject.Web\myproject.Web.AzureFunctions\myproject.Web.AzureFunctions.csproj] "C:\Users\me\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.2.0\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets" cannot be imported again. It was already imported at "C:\Users\me\.nuget\packages\microsoft.net.sdk.functions\1.0.38\build\Microsoft.NET.Sdk.Functions.targets (64,3)". This is most likely a build authoring error. This subsequent import will be ignored. [D:\myproject.Web\myproject.Web.AzureFunctions\myproject.Web.AzureFunctions.csproj]
Worse still my project would not build - it freezes on build with no way to cancel. The only way to cancel was to do, elevated PowerShell:
stop-process -name "dotnet"
To fix this I tried uninstalling the NuGet package but this is not enough as it still seems to be used if it is on the system (even though the project does not reference it?!?).
It is necessary to actually delete the package from package store, i.e. at.
C:\Users\me\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator
Or an alternative is to comment out the lines:
<GenerateFunctionsExtensionsMetadata SourcePath="$(_FunctionsExtensionsDir)" OutputPath="$(_FunctionsExtensionsDir)"/>
From:
C:\Users\me\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.2.0\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets
I have no idea if this is safe to do so but it gets rid of the warning message. I instead opted to just delete the NuGet package and live with the original warning.
Looks like a real mess with microsoft.net.sdk.functions package.
I create a new Net Standard library, and I would like to publish the package to a local nuget repository.
In order to achieve it, I have two ways: using the command line, or using the publish option offered by Visual Studio.
Using the command line I use the "add" keyword from the command line (due to the fact it is a non-http package source), and it works fine, it create the nuget package with its nuget.sha512 file.
Using the publish option offered by Visual Studio, I've not been able to replicate the previous behavior, because it replicate the "push" keyword in the command line.
In the same local repository I can't hold two different packages, one with .nupkg.sha512 file and the other without it, because the nuget package manager will find only these packages without the ".nupkg.sha512" extension.
Is there any way I could tell to Visual Studio to replicate the "add" behavior using the publish option?
Thanks in advance.
Is there any way I could tell to Visual Studio to replicate the "add" behavior using the publish option?
I am afraid there is no such directly way that you could tell to Visual Studio to replicate the "add" behavior using the publish option, because the add command is only supported by NuGet CLI. We could not use it directly with publish option.
As workaround, you can add custom target to call NuGet CLI when you publish your project.
To accomplish this, edit your project. Then at the very end of the project, just before the end-tag </project>, place below scripts:
<Target Name="AddPackage" AfterTargets="GenerateNuspec">
<Message Text="Add Package to the local nuget repository!"></Message>
<Exec Command="<PathOfNuGetCli>\nuget.exe add "<PathOfPackage>\xxx.1.0.0.nupkg" -source "<localNuGetRepository>""></Exec>
</Target>
Note: Since this custom target depends on the target GenerateNuspec, it will be executed twice, but not worry about it, it will not have any actual operation when it is executed in the first time(The package has not yet been published to the specify folder).
Hope this helps.
In line with the rules, I have to ask a new question, to get some clarification on another question/answer.
This answer is this one: https://stackoverflow.com/a/45964469/305916
Then what? Just did the accepted answer, but the packages.config file is not populated with the packages (I know it doesn't say so).
I am missing what to do next if the packages appear automatically in the packages.config or I need to install them again...
I am leaning towards the latter, but I feel the answer is not complete :)
But what to do?
Firstly, do you mind editing your question, or posting as a comment, why you want to revert back to packages.config? As a member of the NuGet team, it's useful to know the reasons why PackageReference doesn't work for you. If it's not one of the reasons listed in as a limitations of PackagesConfig, including the package compatibility section, perhaps we can help resolve that issue so you can keep using PackageReference.
If you really want to revert to packages.config, I suggest the following, not the answer that you linked.
Go to Options, NuGet PackageManager->General and enable Allow format selection on first package install
Uninstall all packages in your project using "Manage NuGet Packages" (Package Manager UI). You can use Package Manager Console to uninstall, but you must use Package Manager UI for the next step. Keep track of which packages you uninstall, so you know which to install again in the next step.
Once your project has no package references, then install the packages you need again. The first package you install will pop up a dialog where you choose to use packages.config or PackageReference. If you didn't keep track of which packages you uninstalled in the previous step, use your source control system to diff your project file, or look at an unmodified copy, and look for all instances of PackageReference.
It's necessary to uninstall all packages in the project installing a new one, because if any PackageReference exists in the project file, NuGet will add new packages as PackageReference. Therefore you can't uninstall the first package, re-install it, then move the second package in the project.
I am missing what to do next if the packages appear automatically in the packages.config or I need to install them again...
Yes, you have to install those packages again. That because automatically migrating projects from PackageReference -> packages.config is not something that will be supported.
Check the thread:
https://github.com/NuGet/Home/issues/4973
To accomplish this, you can follow below steps:
First, change the Package Management to Packages.config, Tools->Options->NuGet Package Manager->Package Management:
Second, unload the project and edit it, remove all PackageReference elements out of the project file (Make sure that is not set in the project file.).
Third, reload the project, then reinstall those packages.
Hope this helps.
I am using VS 2017. I have this line in my packages.config file.
<package id="System.IdentityModel.Tokens.Jwt" version="4.0.4.403061554" targetFramework="net461" />
I got this error my trying to start my .net application.
System.TypeLoadException: Could not load type 'System.IdentityModel.Tokens.NamedKeySecurityKeyIdentifierClause' from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Because System.IdentityModel.Tokens.NamedKeySecurityKeyIdentifierClause really does not exist in version 5.2.1.0. But it seem NuGet simply ignores the version specification, and always loads the latest version.
I have tried to clean NuGet caches, clean and rebuild entire solution, and restart computer...
Is there anything else I can do?
Update
One strange thing I observed in VS 2017. Notice the differences of the icons for System.Data and System.IdentityModel.Tokens.Jwt. When I try to check the properties of the latter, VS says the package is not installed, which it clearly did. The build went successful, but the application just wont load the right version.
There are a couple of steps you can perform to check that the right version is loaded:
Rebuild your solution to make sure all NuGet packages are restored and that the started application is up to date (You already did that).
Check the tag HintPath for the reference in the project file that references the package. Just open the file in a text editor and look for an XML tag starting with <Reference Include="System.IdentityModel.Tokens.Jwt. Make sure that no version-specific reference is set or that the version matches the version in the packages.config file.
Check in the properties of the according reference in Visual Studio that it is resolved correctly. That means, there must be no yellow exclamation-mark icon on the reference in the solution explorer and in the properties of the reference, the Path entry must point to the installed package. Hence, the path should point to the packages directory inside your solution directory and therein into a directory System.IdentityModel.Tokens.Jwt.4.0.4.403061554.
In most cases (from my experience), there is some mismatch between the reference in the packages.config file and in the project file. If that does not help, make sure that no other module is loaded by your application that has a reference to System.IdentityModel.Tokens.Jwt in version 5.2.1.0.
So far, it is still unclear why VS cannot handle the changes of the NuGet packages, and why it thinks my project is using both .Net Framework and .Net Standard at the same time. I bet it is a but in VS, and hope MS can fix it soon.
Before that, installing Rider and use it to fix the packages, then went back to VS, and everything went back to normal.
We have downloaded a project from TFS and after restoring Nuget packages we are getting below error:
Error 5 The "ValidatePackageReferences" task could not be loaded from the assembly projectPath\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.Tasks.dll. Could not load file or assembly 'file:///projectPath\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. projectName
We have not used Task anywhere. It seems it is being used internally. Any pointer how to get rid of this error?
Mostly it looks like its because of wrong version of NuGet package. But not sure whats root cause.
We are using VS 2013 Update 5 version.
First search "Microsoft.Bcl.Build.Tasks.dll." nuget on google. Then a link will be opened with named "https://www.nuget.org/packages/Microsoft.Bcl.Build/". Then copy the package name shown on the site like this
Install-Package Microsoft.Bcl.Build -Version 1.0.21
Then Open the Visual studio , Goto Tools>Nuget Package Manager>Package manager console. Now paste the copied install package,Install it. Then restart the VS.Issue will be solved.