Force evaluate floating version packages with lock file via MsBuild / csproj - c#

I want to use the Locking dependencies of Nuget (>= 4.9), so I can have automatic package update during dev phase and fixed version during release build.
I enabled the lock file mode, so I now have a packages.lock.json file.
The problem is that when I have floating version of package references in the project file like:
<PackageReference Include="My.Nuget.Package" Version="1.0.*" />
The restore package via Visual Studio Build does not update to new packages version anymore. This behavior appeared after I activated the lock file.
The Microsoft documentation describes the --force-evaluate option with dotnet.exe, that works well but I want to do this directly with an MsBuild option in the csproj.
By checking the NuGet Client code, it seems that a RestoreForceEvaluate option exists in Msbuild NuGet.targets but I have no idea how to use it.

By checking the NuGet Client code, it seems that a RestoreForceEvaluate option exists in Msbuild NuGet.targets but I have no idea how to use it.
I am afraid we could not do that at this moment. According to the nuget wiki,
Enable repeatable package restore using lock file:
There is no such MSBuild equivalent option for option --force-evaluate, so we could not use --force-evaluate directly with an MsBuild option in the csproj.
Hope this helps.

Related

Visual Studio SourceLink Nuget Integration with Separate Solution Debugging

I have a library of nuget packages we use throughout our solutions, hosted in Azure Artifacts. These nuget packages are built with debug enabled so symbols are created and included in nuget packages.
Our projects in Visual Studio (mainly Net Core 3.1) reference these nuget packages in the normal way using Nuget Package Manager.
Each solution has SourceLink enabled so if I have any debugging requirements which require stepping into code within the referenced nuget package, I can set a breakpoint and do so quite nicely as Visual Studio downloads the sourcecode directly from Azure Artifacts.
That all works perfectly.
The issue is a productivity one. If code within the nuget package needs to be changed, I have to open the solution for the nuget package, change it, push it and wait for Azure to build. When built, I go to Nuget Package Manager, update the package, restart the app and 'hopefully' have resolved the issue. For something tricky, I can loop this process a few times which is a productivity killer.
Is there any way to debug directly in the solution for the nuget package from the solution referencing it? Or does anybody have a better process they use which is more productive?
You may try to use floating version that can resolve to the latest version in nuget. In this way, when there is updated package, your solution will load the latest version of the package during build.
<ItemGroup>
<PackageReference Include="NuGet.Packaging" Version="*" />
</ItemGroup>
Is there any way to debug directly in the solution for the nuget package from the solution referencing it?
Using project reference instead of the nuget package when you need to frequently modify and debug the source code in the nuget package.
When you consider production efficiency, please consider using project reference, when you consider portability, please try to use nuget. You could check my previous thread for detailed explanation.
For your situation, you could add the project for the nuget package to your referencing solution by the option Existing project:
Then select the project file .csproj for the nuget package.
After adding that project into your solution, you could add that project as project reference for your referencing project. Now, you could directly modify and debug the project for the nuget package.
When you finish this stage of work, you can return to the solution where the project for the nuget package is located, pack the new version of the nuget package and publish it.

Is there a way to update nuget package with multiple interdependent dependencies to a newer version in an old csproj format project?

We have a Visual Studio solution with old(pre VS2017) format csproj projects with dependency on Microsoft.TeamFoundationServer.ExtendedClient 15.112.1 that has a fair share of other (inter)dependencies it requires.
The problem is that even in a new standalone project it is impossible to update (in VS2017) dependency to the newer 15.131.1 version. There is always the following error (regardless of the options I try):
PM> Update-Package Microsoft.TeamFoundationServer.ExtendedClient
Attempting to gather dependency information for multiple packages with respect to project 'TestTfsNugetUpdate', targeting '.NETFramework,Version=v4.5'
Gathering dependency information took 6.98 sec
Attempting to resolve dependencies for multiple packages.
Update-Package : Unable to find a version of 'Microsoft.VisualStudio.Services.Client' that is compatible with 'Microsoft.TeamFoundation.DistributedTask.Common 15.112.1 constraint: Microsoft.VisualStudio.Services.Client (=
15.112.1)'.At line:1 char:1
While the same standalone new format project has no such issues
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net45</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.TeamFoundationServer.ExtendedClient" Version="15.112.1" />
</ItemGroup>
</Project>
As
Update-Package Microsoft.TeamFoundationServer.ExtendedClient -DependencyVersion Highest
Restoring packages for C:\Projects\TEST\TestTfsNugetUpdate\TestTfsNugetPackage_NewFormat\TestTfsNugetPackage_NewFormat.csproj...
Installing NuGet package Microsoft.TeamFoundationServer.ExtendedClient 15.131.1.
...
Successfully installed 'System.IdentityModel.Tokens.Jwt 5.1.5' to TestTfsNugetPackage_NewFormat
Executing nuget actions took 97.55 ms
So, basically is there a way to do it with old format project without resorting to manual/semiautomatic removal and reinstallation of the ExtendedClient with dependencies (the problem is that the solution includes a lot of projects that may or may not depend on TFS dlls, so I can't just remove+install it for each project)?
P.S.: Porting everything to a new format is a nice idea in any case, but it is not something I'd like to undertake at the moment.
Is there a way to update nuget package with multiple interdependent dependencies to a newer version in an old csproj format project?
I am sorry for this late reply, I am not sure if this answer is helpful to you.
I could reproduce this issue on my side, but it seems we have to uninstall and reinstall the version 15.131.1.
Just like you said, the package Microsoft.TeamFoundationServer.ExtendedClient has multiple interdependent dependencies, like:
Microsoft.VisualStudio.Services.Client (= 15.112.1)
Microsoft.TeamFoundationServer.Client (= 15.112.1)
However, the dependencies Microsoft.TeamFoundationServer.Client also has a indirect dependence Microsoft.VisualStudio.Services.Client (= 15.112.1). When we update the package Microsoft.TeamFoundationServer.ExtendedClient, nuget will update package Microsoft.VisualStudio.Services.Client (= 15.112.1) first, but package Microsoft.TeamFoundationServer.Client (= 15.112.1) still reference it, will prevent us from updating the package.
The reverse is the same. Multiple interdependent dependencies of this package form a deadlock, we could not break it for now unless we upgrade every dependencies with option ignore dependencies.
So, we have to uninstall and reinstall the version 15.131.1.
the problem is that the solution includes a lot of projects that may
or may not depend on TFS dlls, so I can't just remove+install it for
each project
You can use the option Manage Nuget packages for solution..., and select the project checkbox, all the project which installed that package will be selected:
So, you do not need uninstall and reinstall the package for each project one by one.
Hope this helps.

how to do 'check in' to code that uses Nuget package

i want to do 'check in' to code uses Nuget package.
what is the the best way to do it?
Do i need to do 'check in' to the package folder?
Is there any way to put the dll's (nuget's dlls) in GAC and add them public key token?
My solution is written in c# .net framework 4.5. TFS version - 2015
thanks!
You should not check in NuGet packages into TFS Version Control. As one of the advantages of using NuGet is that you can use it to avoid checking in binaries to your version control system.
In VS, you can enable package restore:
In TFS, you need to restore NuGet packages during TFS build process by adding a "Nuget Package Restore" task to your build, and the required packages will be downloaded.
More information, refer to this article: https://docs.nuget.org/ndocs/consume-packages/package-restore

NuGet has problems with missing packages, how to restore?

When I try to compile my program I get the following error:
This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=317567.
Now when I right click on the solution and press
All packages are already installed and there is nothing to restore.
I tried manually reinstalling every package which didn't solve the problem, I tried reinstalling NuGet but that didn't help either and I even tried reinstalling visual studio.
I also tried moving the package folder from the tfs folder to overwrite my package folder but that didn't solve anything. I also tried redownloading them with this package missing, that didn' t solve the problem either.
Anybody know how to restore the nuget packages?
Use Package Manager Console in Visual Studio to run this command.
1.This will restore all packages from solution
nuget restore YourSolution.sln
2.If you want to reinstall the packages to the same versions as were previously installed
Update-Package -reinstall
Honestly, whoever developed the NuGet command for VS needs to go back to the drawing board. They totaly missed the fact that sometimes these DLL(s) and/or files get corrupt or deleted. a "NuGet Get-Packages -Force" option would really save their bacon. The only GAP I see is that VS and the Package console does not allow you to invoke a forced download from NuGet. Even clearing the cache via VS is useless.
I ran into this issue when I tried to build my project on a computer where the packages-folder did not already exist in the solution root.
When the project file was initially created, it seems VS2019 added the following into the project file:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
</Target>
From what I understand those settings are deprecated nowadays, no idea why VS inserted it in the first place.
Anyway, after removing those lines VS restored the packages and built the solution correctly again.
It's probably a good idea to clear the Nuget Cache by deleting the contents within this directory: C:\Users\{your_username}\AppData\Local\NuGet
All you need is that:
Open the Package Manager Console and run this command: Update-Package -reinstall
P.S: VS2017 and above NuGet Package Manager is included with Visual Studio, no need to install anything else.
The problem with the functionality of the NuGet package can also be caused by the fact that NuGet package is requiring certain dependency that the project does not meet.
NuGet package can have a declared dependency in Dependecies section, e.g. .NETFramework,Version=v.4.6.2 while the project is targeted to an older version (Target framework: .NET Framework 4.6.1.).
Instead of the NuGet system notifying the user of this fact, the project simply does not compile.
In my case, I have different Nuget configurations, and somehow the HintPath in the project file didn't fit.
Maybe you should check if the HintPath leads to the right NuGetPackages folder.
You should also check the following entries at the top of the file:
And at the bottom of the file:
All these paths should point to the right NuGetPackage folder in your file structure.
In my case the problem was solved by deleting the "obj" folder(s) and then rebuilding the solution.
The "obj" folder had several NuGet related files that still referred to version 0.0.2 of a package while all projects in the solution were already using version 1.0.0 of that package. Building the solution failed with the error message "package with version 0.0.2 could not be found". The solution with build folders included was recently copied from another machine.
Well it's probably a bad way but I found that it works if I just delete the line
http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
from the project.csproj , not sure if this is going to cause problems later on but it works for now.

NuGet auto update specific package

I am attempting to configure my project / nuget to auto update a specific nuget package. I am currently using NuGet Version 2.8.* and an using the Automatic Package Restore in Visual Studio strategy. My question is what is the best approach to get NuGet to auto update a project before my app builds? Is what I am trying to do even possible using the Automatic Package Restore strategy? Or do I need to use Command-Line Package Restore wrapped in MSBuild, and specify custom update command and target in the NuGet.targets file?
Not currently possible with Visual Studio tooling. NuGet will not automatically upgrade your package version. You must still do this manually.
Not recommended, but in theory, you could write your own script to query nuget.org for the latest version and then upgrade the version number in packages.config. But this seems like a dangerous approach.
This is an old post but in case someone lands here.
One option could be using pre-build script to run below command:
nuget update configPath packageid
Config path could be either project ".cproj" path, solution (.sln) path, or the package.config file path.
https://learn.microsoft.com/en-us/nuget/tools/cli-ref-update
Note that it seems nuget CLI does not work for .NET Core. For Core you need to use dotnet CLI which has integrated nuget command. But that does not have a separate update command (at the time of this post). You need to use add to update but that command needs an explicit version number.
So a workaround could be calling remove and then add commands.

Categories

Resources