I have came across this line of code in a code and its quite confusing
One of my client send a dependancy file that contains
<ItemGroup>
<PackageReference Include="xyzrefrence" Version="1.3.0" />
and said it is console application. I created same kind of application but within packages.config
I found this thing
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="xyz" version="1.7.7.7" targetFramework="net452" />
My question is that where the dependacy file located with the client setting(First settings)
The reference (<ItemGroup><PackageReference.....) to the dependency can be
found by editing the Visual Studio project file. *.csproj
The dependency file itself can be found in your project's /bin/debug or /bin/release folders.
Where is PackageReference located in console application C#
There are two nuget mamangement format(Packages.config and PackageReference) to intall nuget packages.
In fact, PackageReference is a new nuget management format for new sdk projects(net standard and net core) since VS2017 while Packages.config is an old tranitional nuget management format for net framework projects.
However, you should note that for traditional framework projects, Microsoft made a concession to use the new SDK's pacakgeReference format, but there are still various compatibility issues.--------(net frameowork projects can use both of them while net core/net standard projects can only use PackageReference).
If you use a net framework project, you can change these two format before you install nuget packages at the beginning by Tools-->Options-->NuGet Package Manager-->General-->Package Management.
And you should specifiy this format before you install the first nuget package at the beginning and when you specify this format, the nugets you install later will use this method by default and cannot be changed.
My question is that where the dependacy file located with the client
setting(First settings)
1) If you use a net framework console project with PackageReference, l am afraid that you cannnot see the depenencies of the nuget. The old sdk projects with PackageReference does not support showing the depenencies of the nuget packages due to several compatibility issues.
2) If you use a net core console project, you can see the dependencies in the Solution Explorer and the latest new sdk projects does support this. It has a new behavior that you can see every nuget package's depenencies under its branch in the Soluton Explorer.
Besides, since you use a framework project with packages.config, you can only see all of them(the premise is that this nuget package has dependencies.) in the packages.config file or in the xxxx.csproj file but it cannot subdivide dependencies for every nuget package.
In additon, if you still want to show the depenencies of the net framework projects with PackageReference, l suggest you could post a feature request in our User Voice forum(DC)-suggest a feature to get Micorosft's attention.
Related
All .NET framework projects that use Nuget have a packages.config per project. When I run something like:
nuget update MySolution.sln -Id PackageName -Version 1.2.3
It will update all projects in my solution that use this package to the specified version (1.2.3 in this case)
However, I'm finding that this does NOT work for UWP projects. UWP does not use packages.config and instead put the package references directly into the csproj file. As a result, this is literally what nuget update says when I run it:
Found 2 projects with a packages.config file. (A.csproj, B.csproj)
where A and B are my .NET Framework projects that still have a packages.config file. But this list doesn't include my new UWP projects.
Is there another command for nuget update that will work with UWP projects?
How do I update UWP projects' nuget packages via the CLI?
This is a known issue for the packagereference. At the moment, NuGet CLI does not support automatic package updates to the the new .NET Core .csproj format, you can refer to the below GitHub issue for details:
support for updating references into csproj from commandline(s)
Besides, as test, the workaround using following command line does not work with UWP project
dotnet add package <PackageName> --version <version>
Indeed, currently it is very inconvenient to manage packages outside of Visual Studio for UWP with packagereference.
Hope this helps.
I recently upgraded our ASP.NET Core 1.1 application to 2.x. This project (and all other projects in the solution) now target the full 4.6.1 framework (previously targeted the full 4.5.2 framework). Visual Studio Version 15.5.7.
After doing so, all my class library projects in the same solution have a number of broken/yellow references to NETStandard.Library.2.0.2. Strangely, the solution still builds without issue and no pertinent warnings or errors are generated in the build output. All other references are fine including all references in the ASP.NET project (meaning that project does not have this problem).
Does anyone know what might be going on here?
Troubleshooting Steps
Clean Solution/Rebuild
NuGet Restore
Restart Visual Studio
Remove .suo/.vs/project.fragment.lock.json and restart
Suspend/Resume/Turn off R#
Manually remove and rebuild (works but they come back after NuGet restore)
Confirm the files it's looking for are actually available on the path...which they are sans the strange "double backslash" before ref:
Environment Details
Visual Studio: 15.5.7
Full Framework: 4.6.1
dotnet --info:
.NET Command Line Tools (2.1.4)
Product Information: Version: 2.1.4 Commit SHA-1 hash:
5e8add2190
Runtime Environment: OS Name: Windows OS Version: 10.0.16299
OS Platform: Windows RID: win10-x64 Base Path: C:\Program
Files\dotnet\sdk\2.1.4\
Microsoft .NET Core Shared Framework Host
Version : 2.0.5 Build :
17373eb129b3b05aa18ece963f8795d65ef8ea54
Please feel free to let me know what other information may be pertinent.
UPDATE: As Requested CSProj Sample (Some Things Had to be Redacted)
https://gist.github.com/mikeomeara1/0edd3b83447473accd3350ffc974c62c
The older .NET Framework project system doesn’t properly support .NET Standard Library 2.x, at least at design time. It requires the new .NET Core SDK project system.
A good migration how-to I’ve recently followed — https://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/.
#MattBrooks and #ScottChamberlain are correct and this is a Visual Studio csproj issue and following the link #MattBrooks provided is the correct answer to this question (I've marked it as such). However, I also wanted to share my personal experience with this in the hopes it will help others who find this process convoluted and confusing (and it doesn't seem right to plop this into an update to the question). As Matt says, "it can be very confusing and sometimes the tooling doesn’t help very much."
Here is the exact procedure I used to convert my projects over. After trying to manually convert a couple, I gave up and rebuilt them:
Remove Project from Solution
Copy Project Folder to Backup Location
Add New ".NET Standard" Class Library Project with Same Name
Edit new .csproj and Change <TargetFramework> to net461 (or whatever you need. Note this can't be done from the Target Framework UI Dropdown. All you'll see is "Net Standard").
Copy all <package> elements from backup projects packages.json (if you don't have a package.json see the outline from the accepted answer to convert your csproj <References> to <PackageReferences>)
Create <ItemGroup> in new csproj
Paste in <package> elements
Find Replace:
<package id= --> <PackageReference Include=
targetFramework=".*" --> <blank>
version --> Version
Open Backed-Up .csproj and copy all <Reference Include=... That DON'T HAVE Version=4.1.0.0, Culture=neutral, PublicKeyToken=..." e.g. that look like <Reference Include="System.Web" /> and paste into new csproj and save.
At this point, NuGet will restore your packages.
If you (likely) end up with NuGet Dependencies that have Yellow/Warning Triangles:
Try to build and see if you get any errors/warnings in the error list. I had some versions that didn't jive between projects. Apparently that's a full stop issue now.
I had some Pre-Release NuGet Packages from a Private Feed that I had to re-install manually.
If all else fails, remove the reference from csproj and install directly from NuGet
If all else all else fails, uninstall and reinstall the package from the VS Package Manager
Copy content files and folders from Backup Project into New Project Folder - VS Will Pick them Up and Auto-Add to Project. I also had to copy node_modules for projects that had NPM packages installed from the backup back into the new project.
Add back any solution project references you may have.
Now, the fun part if you're an idiot like me and had files "excluded from project"....you must hunt those down and remove them.
I would also note that if you (like me) had <Reference> tags to packages in your csproj and a package.json, I found that the package.json was accurate in terms of having the correct versions.
I was not able to convert a single MVC4/WebAPI2 project over because there doesn't seem to be a way in the new project format to tell it "This is a web project, run IIS and debug"...in that all new Core projects expect an static void Main. Probably a different question though.
I was able to get the MVC4/WebAPI2 App Migrated Using the Answer Provided here: https://stackoverflow.com/a/49655107/3892531
Good Luck!
I encountered a solution (.Net Full framework) Where there are no package.config in the solution and Feeds coming from In house Nuget servers.
Where list of packages are maintained, if not in Package.Config?
Where is the list of packages are maintained, if not in Package.Config?
First, you should make sure you have that solution have already installed the nuget package, once you install a package, NuGet will add Package.Config file to your project to record the dependency in either your project file or a packages.config file.
If you confirm that your solution has a nuget package installed, but there is no Package.Config file, your nuget package should use another management method: PackageReference
Edit your project, you will find following PackageReference list:
<ItemGroup>
<PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
</ItemGroup>
See NuGet is now fully integrated into MSBuild for more details:
In the past, NuGet packages were managed in two different ways -
packages.config and project.json - each with their own sets of
advantages and limitations. With Visual Studio 2017 and .NET Core, we
have improved the NuGet package management experience by introducing
the PackageReference feature in MSBuild. PackageReference brings new
and improved capabilities such as deep MSBuild integration, improved
performance for everyday tasks such as install and restore,
multi-targeting and more.
The packages.config file could be somewhere else? In that case look in your msbuild project file (i.e. *.csproj, *.vbproj, *.vcxproj) and see where the references to that nuget assembly are coming from. Then look in that directory for the packages.config file. It might be more complicated than that, in which case, it's useful to do a global search for packages.config in your repo, to see where they reside (If they do exist at all).
This is a common practice: To have one project specify the nuget package, and all the other projects borrow it. As Jon said, this is really dependent on how the folks at your company and department set up your builds and dependencies.
I have created a new ASP.NET Core project which targets the full .NET 4.6 framework. So essentially what I want is to create an ASP.NET Core web application with the new .csproj format and the new dotnet tooling, but still target the full framework because we have many dependencies which cannot be ported that quickly to .NET Core.
There are some NuGet packages that include many DLLs, but after adding a PackageReference it only copies one DLL into the bin folder of the web application. Other DLLs I need to manually reference.
For example:
<ItemGroup>
<Reference Include="CustomDll">
<HintPath>..\packages\CustomPackage\version\lib\CustomDll.dll</HintPath>
</Reference>
</ItemGroup>
Now the problem is that with the new tooling and NuGet versions there is no packages folder under the solution path. It is typically in my users folder under .nuget\packages\....
Is there a macro that I can use with the new MSBuild to reference the global nuget folder or a setting that I can change so that the build actually copies all NuGet packages under the solution directory?
It looks like the dll in the NuGet package is placed directly in the lib folder and not lib\net45 which would enable the automatic tooling in that case. (The NuGet package has probably been manually assembled).
As a workaround, you can set the HintPath to $(NuGetPackageRoot)the.package.name\1.0.0\lib\the.dll.
I've been working on this MVC 3 application on my home computer for a while now. I'm out of town on a different computer, so I got the project from my source control. This new computer didn't have MVC 3 yet, so I installed it after I copied the project to the new computer.
A lot of my dlls (like MvcContrib.dll) were missing since I didn't set Copy Local to true when I first created the project on my home computer. So I've been going in and downloading all the missing dlls and adding them to my project.
The only one I can't find is EntityFramework.dll. I can't find a download for it, and I don't see it as a .NET dll when I try to add a reference.
I'm getting this warning when I try to build:
Could not resolve this reference. Could not locate the assembly "EntityFramework"
This can also happen when you manually remove the EntityFramework reference in a project.
If you've lost the reference you can remove the entry in packages.config for EntityFramework
<packages>
<package id="EntityFramework" version="5.0.0" targetFramework="net40" />
</packages>
After removal you are able to re-install the package through the Package Manager (Manage NuGet Packages)
Download and install Framework 4.0 and it's included.
http://www.microsoft.com/download/en/details.aspx?id=17851
You need to download and install Entity Framework separately:
http://blogs.msdn.com/b/adonet/archive/2011/04/11/ef-4-1-released.aspx
If you have not - install the Nuget extension in Visual Studio.
Install ASP .NET MVC 3 Tools Update (using WebPI is easiest)
Then install the EntityFramework Package.
Other packages are likely available for items such as MvcContrib, which may be missing.
Using Nuget will not only enable you to have the packages with the source (in the packages directory), but will also help you keep things up to date. External dependencies you rely on should ideally be included with your solution so situations like yours do not occur.
As The Evil Greebo noted, you will need to go here to obtain the Visual Studio tooling. While the Nuget package will provide the code level support, the tooling is in the installer. I use both, so if there is an update to the package, it will show up in the Nuget update notices.
I resolved a similar problem myself by downloading the ASP.NET MVC Tools Update. Any chance you are just missing that on this other computer?
If EntityFramework was installed previously you can also manually add reference with browse. Select the following file in your project folder: \packages\EntityFramework.5.0.0\lib\net4x\EntityFramework.dll
Then add the following if missing in your packages.config:
<packages>
<package id="EntityFramework" version="5.0.0" targetFramework="net4x" />
</packages>