Transfer nuget Packages to new solution - c#

I've a visual studio 2015 project in a solution. I need to create a very similar project and didn't want to manually add all packages again.
So I copied the packages json and ran "Restore nuget packages" But this command only downloaods the libs and doesn't add assembly references to the project file.
Is there a command line to enforce this ?
I Know I could also copy and adjust the content of the csproj but I'm very courious if there is a built in way.
The packages.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="BouncyCastle" version="1.7.0" targetFramework="net461" />
<package id="Common.Logging" version="3.3.1" targetFramework="net461" />
[...]

With the packages.config copied into your project you can run the following command from the Package Manager Console to reinstall the NuGet packages.
Update-Package -reinstall
You can also restrict this to one project.
Update-Package -reinstall -ProjectName MyProject
The -reinstall parameter will get NuGet to add back the assembly references to the project.

Related

How do I make migrations in Entity Framework?

My research keeps telling me to use the Migrate.exe, which has not shown up in my project, and it cannot be downloaded anywhere. I am also using VS Code and not Visual Studio, which seems to make it impossible to use the Package Manager Console.
And I am using Entity Framework - not Entity Framework Core - so I do not have all the options of EFC.
Currently I am trying to set Entity Framework up in Unity, the game engine. It was possible to set up a temporary project with Entity Framework v6.2.0 and run dotnet pack to get the EntityFramework.dll but it does not create the Migrate.exe. And it seems to be the only option for creating migrations.
Do any of you know how to get the Migrate.exe file or another way to add migrations?
When you install Entity Framework using NuGet migrate.exe will be inside the tools folder of the downloaded package. In \packages\EntityFramework.\tools
Source is microsoft
have you tried this?
Apparently there is a difference in installing and adding, not that they mention that when you look at the package on nuget.org.
So rather than running dotnet add package EntityFramework --version 6.2.0
I needed to download the latest nuget.exe from nuget.org and create a packages.config file in the root folder.
I then ran nuget.exe install packages.config -OutputDirectory packages which installed all the files I needed.
packages.config:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="EntityFramework" version="6.2.0" targetFramework="net40" />
</packages>

Targeting multiple .NET Framework versions in a nuspec file

I have a Visual Studio solution with multiple projects. There is one single csproj for every version of .NET Framework (+ .NET Core) I want to support, and I want to keep it that way. They all generate one DLL each. All DLLs are named the same but are slightly different.
I've recently started generating NuGet packages out of these DLLs using a nuspec file and the command nuget pack. So far, I've generated one NuGet package for each DLL.
Would it be possible to generate one single NuGet package, that contains all the DLLs, and when a user installs the package, installs the right DLL?
I tried the following in my nuspec file:
<?xml version="1.0" encoding="utf-8"?>
<package >
<metadata>
...
<dependencies>
<group targetFramework=".NETCoreApp3.1" />
<group targetFramework=".NETFramework4.0" />
</dependencies>
</metadata>
<files>
<file src="bin\Company.Product.dll" target="lib\net40" />
<file src="..\CompanyProductCore\bin\Company.Product.dll" target="lib\netcoreapp3.1" />
</files>
</package>
When I look in the generated NuGet package, there are the two expected subfolders in the lib folder, and they each contain a DLL which looks right.
However, when I test the package and try to install it in another Visual Studio solution on a .NET Core App project, I get the warning:
Package X was restored using '.NETFramework,Version=v4.6.1...4.6.2...4.7...4.7.1...4.7.2...4.8 instead of the project target framework '.NetCoreApp,Version=3.1'. This package may not be fully compatible with your project.
which is something that did not appear when I packed it separately. So it would seem that it didn't detect that there was a .NET Core-specific DLL given.
Is what I want to do possible, and if so, how?
Your target frameworks should be net40 and netcoreapp3.1.
<dependencies>
<group targetFramework="netcoreapp3.1" />
<group targetFramework="net40" />
</dependencies>
https://learn.microsoft.com/en-us/dotnet/standard/frameworks

Creating NuGet using Team Foundation Server missing dependencies

I have created a simple class library in .net standard 2.0 with a few nuget dependencies like Dapper.
I am using Team Foundation Server 16 to then build and package the project. My issue is, that when I then browse to my new NuGet package, it does not list it's dependencies in the NuGet package manager in VS and I have to install them manually afterwards.
Creating a nuget package of the same class library from Visual Studio 2019 locally works as intended.
My build tasks on TFS are:
Use nuget 5.4.0
NuGet restore
Build solution
Run script (A .bat file for updating version number)
NuGet pack
Publish build artifact
The NuGet pack uses default settings with command "pack" and path pointing only to .csproj file.
Creating a nuget package of the same class library from Visual Studio
2019 locally works as intended.
It's one issue about nuget pack command. When you pack the .net standard project in VS locally, it(right-click=>pack button) actually calls dotnet cli instead of nuget.exe to do the pack job.
For now, nuget pack command can't work well with those projects that use PackageReference to manage nuget packages. (Including .net framework projects with PackageReference,.net core and .net standard projects).
More details see discussions here and here.
To resolve that issue(For TFS2017 and above):
Use dotnet pack command instead of nuget pack command. And for pipeline in tfs, use dotnet restore, build, pack tasks instead of nuget restore, nuget pack tasks.
Update1 for TFS2016:
Since TFS will run those tasks in tfs agents, one alternative way is to install .net core sdk manually, and then use command-line task to execute dotnet pack command to create nuget packages.
.net core sdk download link here.
Update2:
Also, we can still use nuget pack command/task. To include those dependencies, we need to create an extra xx.nuspec file with content similar to this:
<?xml version="1.0" encoding="utf-8"?>
<package >
<metadata>
<id>PackageName</id>
<version>1.0.0</version>
<title>xxx</title>
<authors>xxx</authors>
<owners>xxx</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<license type="expression">MIT</license>
<description>xxx</description>
<releaseNotes>xxx</releaseNotes>
<copyright>Copyright 2020</copyright>
<tags>Tag1 Tag2</tags>
<dependencies>
<dependency id="Dapper" version="1.30.0"/>
//define other dependencies manually here.
</dependencies>
</metadata>
</package>
Place this file in same directory where xx.csproj exists, and then nuget pack command/task can now create the package with dependencies.

Migrate from PCL to .netstandard

I'm trying to figure out how to migrate a project from PCL to .netstandard 1.2.
I have a solution where I have a PCL project (portable45-net45+win8+wpa81) and a .Net Standard (netstandard1.2) project which has all it files linked into the PCL project.
Currently we create a nuget package from the PCL project using a nuspec file.
Now what would be the best approach to have both available in 1 nuget package?
I find the use of nuget pack vs dotnet pack and mixing multiple frameworks and project types (csproj) very confusing.
Also appearantly there is a new csproj format for VS2017+ projects, should I convert the PCL project?
Eventually the nuget should only contain the .netstandard1.2 project but we want to take both up the dependency tree during migration.
what would be the best approach to have both available in 1 nuget package?
You can still use .nuspec file to accomplish this, just need include the dll files from PCL project and .Net Standard project into different frameworks.
Following is my test .nuspec file, you can check it for details:
<?xml version="1.0"?>
<package >
<metadata>
<id>My.Package</id>
<version>1.0.0</version>
<authors>Tester</authors>
<owners>Tester</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package description</description>
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
<copyright>Copyright 2018</copyright>
<tags>Tag1 Tag2</tags>
</metadata>
<files>
<file src="TestPCL\bin\Debug\TestPCL.dll" target="lib\portable-net45+wp8\" />
<file src="TestStandard\bin\Debug\netstandard1.2\TestStandard.dll" target="lib\netstandard1.2\" />
</files>
</package>
When you install this package to the PCL project and .Net Standard project, nuget will select the DLL file under the corresponding framework to your project.

Local NuGet package source not showing package

I'm stumped. I've followed the directions to set up a local NuGet Package Source as closely as I could, but my package refuses to show up in the NuGet Package manager. The screenshot below shows:
I've created the NuGet package
I put the package in C:\Packages
I created a package source Local that points to C:\Packages
In the Package Manager, I've selected Local as the package source
But it cannot find the package. What am I missing?
Here's my .nuspec for reference, with the assembly name removed.
<?xml version="1.0"?>
<package >
<metadata>
<id>$AssemblyName%$</id>
<version>1.2.0-beta2</version>
<title>$AssemblyName$</title>
<description>Orders Messages</description>
<language>en-US</language>
</metadata>
<files>
<file src="bin\Debug\$AssemblyName$.dll" target="lib\net40" />
</files>
</package>
Your NuGet package is a pre-release based on the version since the version in your .nuspec is:
1.2.0-beta2
So you need to check the Include prerelease check box before your NuGet package will appear in the NuGet Package Manager. Without this checked only stable versions will be displayed.

Categories

Resources