I have a simple asp.net 5 web application.
My project.json file contains dependency:
"Microsoft.IdentityModel.Tokens": "5.0.0-rc2-301060021"
When I restore nuget packages, this package is restored well on my machine. project.json file is in source control, but it does not work on other machine. It says that this package is not found.
Anyway, in nuget configuration Im pointing to my local nuget packages repository, which does not even contain asp.net 5 nuget packages. Where all of these packages come from?
RC2 has not yet been made public, we're still on RC1. Here is the roadmap schedule, which indicates sometime this year. If you do somehow have the package on your machine, you could setup another NuGet feed that others on your project could point to -- then simply place the package in there, so it's on shared feed.
Here is some helping documentation that shows you how to do that.
Related
I'm getting the error.
The command:
"C:\ProjectDir\.nuget\NuGet.exe" install "packages.config"
-source "https://www.nuget.org/api/v2/"
-NonInteractive
-RequireConsent
-solutionDir "C:\ProjectDir\ "
exited with code
-1073741502 while building one of my Class Library projects in my solution.
As a result, I'm getting many
Metadata file 'C:\ProjectDir\src\ProjectName\bin\ProjectName.dll' could not be found`
errors from other projects in my solution.
When I click on restore packages for the solution it shows that there are no packages to restore.
Any idea about the fix?
While it's interesting to know that NuGet exited with an error code, it's far more interesting and useful to know what the program's output is. By not sharing that with us, we have to do a lot of guessing, reducing the chance that you get an answer that helps your specific case.
Anyway, NuGet.exe's program returns 1 for almsot all error codes (unless something throws an ExitCodeException, but it appears that only signing related code returns anything other than 1). Therefore, I conclude that NuGet didn't actually run. My best guess is that you ran on a machine without recent versions of the .NET Framework installed, but you're running a newish version of nuget.exe that needs a newer .NET Framework.
You also didn't say what version of nuget.exe you're using. NuGet 5.x is designed for Visual Studio 2019, which has a minimum requirement of the .NET Framework 4.7.2. NuGet 4.x is designed for Visual Studio 2017, which has a requirement of .NET Framwork 4.6. However, Wikipedia says that the .NET Framework was released in April 2018, which suggests to me that if you don't have that installed, you're not running Windows Update and so you're probably vulnerable to all sorts of malware. Perhaps you've just turned off recommended updates and getting only the critical updates, but it's worth checking.
So, while I expect this to be the cause of the problem, I also want to comment that it's normal to run nuget restore, not nuget install, to restore packages for projects and solutions. Also, it's typical to simply run nuget restore mysolution.sln. This has several benefits. NuGet can restore the entire solution more efficiently than one project at a time. Secondly you no longer need to provide the -SolutionDir argument.
One possibility about why you're restoring one project at a time is hinted by the fact that you're running some_path\.nuget\nuget.exe. This was done in Visual Studio 2010, VS2012 and VS2013, but was removed from VS2015 onwards. Back then it was enabled by right clicking the project and selecting "Enable NuGet restore for solution" or something like that. This was because NuGet was not really integrated with Visual Studio back then, other than adding this command which would modify all your .NET project files and create the .nuget/ directory with 3 files. Since then NuGet is integrated with Visual Studio and can do automatic restores without hacking project files, so it's no longer needed. NuGet has docs on migrating to automatic package restore.
The only advantage of the old package restore that changes the .NET project files is that on a CI machine there's nothing extra to do. Simple clone the repo and run msbuild. Once it's removed, it's necessary to run nuget restore on the solution file before building, to restore packages.config projects. If you can migrate to PackageReference (needs Visual Studio 2017 or later), then the NuGet restore step isn't necessary, you can run msbuild /restore mysoltuion.sln, or if all projects in the solution are SDK style, just dotnet build. Although some people still prefer to separate restore and build into separate steps, so when there's a failure, it's more obvious if it was a restore or compile error.
I have a solution with a number of projects.
I have changed system.Net.http to use the NuGet version, and most projects, when i select the "System.Net.Http" reference in the references node of solution explorer, it shows the path as "X:\myPath\packages\System.Net.Http.4.3.4\lib etc..."
However, i have a couple of projects when removing reference to System.Net.Http then going to NuGet Package Manager and installing it, when you click reference in the reference node, the path shows as "C:\Program Files etc.... Microsoft.NET.Build.Extensions\net461\"
I have opened the project file, and the "HintPath" is correct, however the path that shows in the reference Properties is incorrect.
When i look at Object Browser, it confirms this project is actually calling the framework version of System.Http.Net (so, even though i have installed NuGet version, and the HintPath is pointing to our packages folder, its still referencing the framework version)
Does anyone know why the path isnt matching and how I can fix this (so my project is using NuGet version instead of framework version to match the other projects in my solution?
Just incase it helps, here are all the references in the problem project:
I have a theory: it's a hack implemented in Visual Studio in order to workaround an issue with the package System.Net.Http.
There are issues with this package and it seems we should not use it anymore. The version of the System.Net.Http library included in the .NET Framework is better starting from 4.7.2 if I understand correctly.
See:
https://github.com/dotnet/corefx/issues/11100
https://github.com/dotnet/corefx/issues/17522#issuecomment-338418610
https://github.com/dotnet/corefx/issues/29622
I'm currently moving projects to .NET Framework 4.8 and I'm removing all System.Net.Http packages.
I have ASP.NET MVC 5 application with .NET 4.5.1. The application is having issue as described in this SO post.
So as per the suggestion i am trying to install https://github.com/Sustainsys/owin-cookie-saver nuget package However i am getting error
Severity Code Description Project File Line Suppression State
Error Could not install package 'Kentor.OwinCookieSaver 1.1.1'. You
are trying to install this package into a project that targets
'.NETFramework,Version=v4.5.1', but the package does not contain any
assembly references or content files that are compatible with that
framework. For more information, contact the package author. 0
any idea?
Right now, the ASP.NET MVC 5 app you have is targeting .NET 4.5.1. No surprise there. The error says "You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.1', but the package does not contain any assembly references or content files that are compatible with that framework."
The highlighted line indicates that the package you are trying to install is not built for .NET 4.5.1. I went ahead and downloaded the package itself (from NuGet.org). The package is currently targeting .NET 4.5.2. So if you change your target framework to .NET 4.5.2 and try to install, you will find it works out for you.
Ideally, packages available to the public would be built for a wider range of Target Frameworks but occasionally I do run into this. If you run into this again, go grab the package from the previous link (see the Manual Download on the right hand side of the page). Open up the .nupkg using 7-zip and open up the lib folder. There you will find what frameworks it is targeting and can adjust accordingly (or decide to try another package if you can't change).
I have a webforms projects with entity framework 5 and .NET 4.5. When I'm publishing the the web site it generates 'packages' directory in the compiled code, with some entity framework dll's in it. However the website functions well even If I remove it. It should be mentioned that I don't use code-first.
What is the purpose of this folder?
TIA.
First, make sure you're using EF5, as version 5.0, not the 4.4 that may happen if you first installed the EF5 on .net 4 and updated to .net 4.5 later.
http://thedatafarm.com/data-access/when-entity-framework-5-ef5-is-not-entity-framework-5-ef5/
From EF5 on, entity framework is a separate api(package) that can be installed via Library Package Manager or NuGet from Visual Studio, it is not part of .net framework installation any more.
packages folder is a default one for NuGet package installation.
So, please have a look at the EntityFramework reference that must be present in your project where you actually work with EF, and see the version and the location of assembly you are referencing. If your Copy Local property is set to true, you don't need to include packages folder in your installation package, assembly will be copied to bin folder automatically, otherwise you'll have to.
The short answer to your question is : No, you don't need the packages folder
Long answer : No, you don't need the packages folder in production, its created by nuget when you install a package to hold the dlls for that package.
So if you include EF in your project it will be copied in there and a reference will be added to your project to ~/packages/Entityframework.dll, at compile time a copy of the dll will be put in your bin folder.
During releases to our live environment I routinely remove this folder as its not needed.
I read about Web API having its own TraceWriter implementation with 2012.2, for example here, among other sources.
I am now using VS2013 with .NET 4.5.1 and the EnableSystemDiagnosticsTracing is nowhere to be found. It's meant to be defined in the HttpConfigurationTracingExtensions class which resides in the System.Web.Http.Tracing.dll. However, this assembly is nowhere to be found - not in list of assemblies in the Add Reference dialog, not in GAC.
Where is this assembly supposed to come from? Docs say it's part of .NET Framework 4, which I have installed. Also installed the ASP.NET Web API 2 Tracing 5.0.0 NuGet package. Is there some update? Should I re-install .NET Framework?
I know it's not a big deal to implement ITraceWriter myself but it bothers me not to know what happened with the built-in implementation.
Just install needed NuGet Package
Install-Package Microsoft.AspNet.WebApi.Tracing -Version 5.0.0
It's a little bit strange, but it is the right package
http://www.nuget.org/packages/microsoft.aspnet.webapi.tracing
If you installed the Tracing 5.0.0 NuGet package, it should be correctly included in your project. The moment it is installed, I believe a separate text file should open in VS showing the code you should include in your WebApiConfig.cs file.
I haven't created a Web API 2 project from scratch (only upgraded from pre-5.0 to 5.0 projects), but this is the code that should reside in your WebApiConfig.cs file:
// To disable tracing in your application, please comment out or remove the following line of code
// For more information, refer to: http://www.asp.net/web-api
config.EnableSystemDiagnosticsTracing();
And that should be it, if the package is installed correctly, tracing should now be used in your project.