I am generating a NuGet package of a library in .NET Standard 2.0 using Visual Studio 2022.
I go to Project properties and edit the project information as shown in the pictures.
When i use the command NuGet specto generate the manifest, the values are not corresponding to the project metadata edited in Visual Studio.
I tried several solution found on web but none worked, even unloading the project, reloading and cleaning it. It looks like nuspec is ignoring the properties of the project.
I know I can edit the metadata by hand, but I am wondering why this happens. If I make several rebuild of the package I have to edit manually the entire spec file each time.
I have found out that there is no need to call NuGet spec and follow the manual procedure in order to create a package in Visual Studio 2022.
In Visual Studio 2022, it is enough to right-click the project and select Properties.
Then in the Package section, check the box Produce a package on build.
A NuGet package of the project, using the metadata provided in the project properties, will be created in the bin/Debug or 'bin/Release` folder. The folder depends on your building choices.
Related
When I try to add a missing assembly to my project (for unit testing specifically) I noticed that the Assemblies tab is missing in the "Add Reference" dialog , see:
Is this a bug or a expected behavior? If it's expected how we are supposed to add the missing assemblies.
Note that I already tried through Nuget package manager and still didn't work.
It is correct behaviour. The Assemblies tab is not available for Net Core projects. You wont be able to add assemblies from your system, because Net Core projects work with dependencies from Nuget. So, to add your references, you need to use the Nuget Package Manager instead.
Right click your project
Choose "Manage Nuget Packages"
Find the package you want to add from the list
You can add external assemblies, e.g. Rebex, by right clicking your project, select Add >> Project Reference... >> Browse and then hit the Browse button.
I've just done that using VS2019 v.16.9.4 on a .Net Core 3.1.x project. No problem at all.
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.
Recently installed Visual Studio 2017.
Usually, when you create a new project, you immediately fire it up and run the scaffolded code.
Unfortunately for me, the new project doesn't have the required packages making the build fail.
Also, objects in the code are marked as not recognized. This is also correct for javascript dependencies.
4 new projects of different types, same result. Didn't even change the code yet I can't build.
The light bulb icon doesn't even show the dependency. Visual Studio doesn't recognize it.
How come scaffolded code has missing references??
Please help.
Well, this was annoying...
Package restore was disabled.
Enabled it in Visual Studio's options and ran the project.
Packages appeared magically.
Tools > Nuget Package Manager > Package Manager Settings
I am trying to follow the tutorial from the command line. I have generated the project and deployed the blank website then added a vs2012 project to the source folder maintaining the original heirarchy. I have edited the docfx.json file to include "src/.csproj" "src/.cs*" which i assume are searched recursively. The project was previously commented for use with SandCastle so there should be plenty to extract or generate metadata from. I currently have vs2012 msdn installed. My issue is that the metadata never builds and even when I'm using the sample seed project all the md files show up on the webhost but not the documentation from the source files.
There is no requirement to have the complete VS2017 installed, instead you can just install the build tools of VS2017. Download
Just start a developer prompt for VS2017 environment and do docfx from there, it should then be able to extract metadata. I had problems with VB.NET projects with docfx and older Visual Studio tooling for some reason.
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.