I have a few solution level NuGet packages attached to a Visual Studio 2010 solution via .nuget/packages.config.
These packages each contain a Init.ps1 file. I'm trying to pre-install the packages via commandline or script on my CI server. Running nuget install .nuget\packages.config -o packages pulls the packages down into the packages folder. But it does not run the Init.ps1 scripts.
If I attempt and msbuild call on the solution file, it fails because required files installed by the package Init.ps1 files are not in place yet.
If I open up the solution in Visual Studio, the packages run Init.ps1.
How can I get the Init.ps1 files to fire along with the package install from a commandline/script without having to open Visual Studio?
The best you can do is fake it. Run the scripts by hand by invoking PowerShell. But there might be problems with them. The $project argument passed to init.ps1 is a DTE object, and you can't make it available without a full copy of VS.
Related
I have to do automated testing on a VisualStudio c# Web service Project.
For this I have to download the project using Jenkins, compile it, run it, and then run an automated test on the local webpage, to ensure functionality.
My problem is that when trying to build the project, it won't restore all the NuGet packages needed.
Some of these aren't in packages. config or in project. the project, others are on the web. config but not anywhere else.
I tried nuget.exe and dotNET but these won't download the needed packages
I tried using dotNET to add packages to the project but there's an error:
"El proyecto no permite agregar referencias de paquete mediante el comando add package"
The project doesn't allow package references through the add package command.
I tried adding the references manually through a script that adds the XML nodes and through that I managed to make NuGet restore download the packages but these were not installed properly, I was left with *.nupkg files that I then had to unzip.
And now that I'm at my wits' end in regards to this issue I need help to solve this problem.
I would prefer if I can be as unintrusive on the developers on the project, but I'll do whatever is needed.
Well, after lots of trial and error i managed to get the project working by making sure the packages.config, Project.csproj and Project.sln files were exactly the same as a working version of the project. After that i use nuget restore to download the packages and unzip them with a .bat file. It isnt pretty but it's what worked.
I'm helping a colleague who cannot get a Visual Studio WPF project to build in our TFS 2015 build server. I've pulled (get latest) the latest version of his code into my VS 2019 instance. I can't get it to build on my dev box. When I try to build the solution on my dev box I get errors like thing:
The tag 'ModernDialog' does not exist in XML namespace 'http://firstfloorsoftware.com/ModernUI'.
The tag 'Interaction.Triggers' does not exist in XML namespace 'http://schemas.microsoft.com/expression/2010/interactivity'.
When my colleague checks in changes into TFS, it fails with errors like this:
Unable to find version '5.2.0' of package 'MvvmLightLibs'.
Unable to find version '1.0.9' of package 'ModernUI.WPF'.
I started by trying to update the NuGet packages he had in the project, but that hasn't worked well. Even restoring back to the latest version doesn't build on my machine.
My colleague's approach is to rip all NuGet packages out of the Visual Studio solution, then look around to find the DLLs, then put them into the project and reference them in the project. It does build on his system but doesn't on the TFS build server.
So, I've been looking around for probable causes. I came across this Microsoft document Migrate from packages.config to PackageReference. I'm not familiar with either packages.config or PackageReference, but I get the feeling that PackageReference is the "preferred" way of including NuGet packages.
This raises problems. Currently our TFS build server's highest version of Visual Studio is VS 2015. According to the referenced article, VS 2015 uses packages.config files. Anything newer than VS 2015 uses Packages (PackageReference I presume).
I've compared the failing WPF solution with another one I've worked on which builds fine on the build server. The solution that builds, I'll call it SolutionA, has a packages folder at the root of the solution, but it also has packages.config files in each project in the solution. The solution that fails to build, I'll call it SolutionB, has the packages folder at its root, and one packages.config file in the unit test project. (I think the unit project builds fine.)
Even though we're working with newer versions of Visual Studio, I suspect that the problem the build server is having is due to the build server having an older version of Visual Studio. We have a limited number of licenses for Visual Studio, so I can't put a newer version of Visual Studio on the build server. So, how do I get those packages.config files into each projects?
First, your solution actually uses packages.config nuget management format. And this format makes every project has a file called packages.config which lists all the nuget packages and their versions. That is the feature of packages.config nuget management format. So you should also make sure that you have commit that file into TFS.
Second, that migrate packages.config into PackageReference is not an easy work and it should be done with VS IDE. Mostly, you have to make a big change to every csproj file of the project. Actually, PackageReference is flexible and lightweight, it does not have the packages.config file and packages folder which stores all the nuget packages. Just embed them directly in proj file. And so far, PackageReference is the mainstream.
Your problem is that you did not do a nuget restore operation on TFS build to make the missing nuget packages under the packages folder so that build process will find those nuget packages and make them work.
You should add a nuget restore xxx\sln command line or task.
Please check one,two,three.
In the company I work, inside every solution we have one folder packages, which contains all dll dependencies. This folder is not in repository with the rest of the solution.
Every time I build one project, all files inside folder packages are restored and any missing dlls appear again. This happens in the beginning of the build, no matter if the build succeeds of fails. Even if the project has no dll dependencies, any missing dlls in packages are restored.
I suspect it is a setting in msbuild but I cannot find it. Does anyone know where it might be or if there is a place with msbuild *.targets files?
thanks for any help
This is because Visual Studio restores packages defined in the packages.config files.
You can control this behaviour in Visual Studio in options:
From the MS Docs regarding regarding Nuget:
MSBuild: use the msbuild -t:restore command, which restores packages
packages listed in the project file (PackageReference only). Available
only in NuGet 4.x+ and MSBuild 15.1+, which are included with Visual
Studio 2017. nuget restore and dotnet restore both use this command
for applicable projects.
Further down, there's quite a bit about enabling/disabling and modifying this behavior in a variety of ways.
Allow NuGet to download missing packages: controls all forms of
package restore by changing the packageRestore/enabled setting in the
NuGet.Config file as shown below (%AppData%\NuGet\NuGet.Config on
Windows, ~/.nuget/NuGet/NuGet.Config on Mac/Linux). In Visual Studio,
this setting allows the Restore NuGet Packages command on the
solution's context menu to work.
Appearing to be more to your issue:
Automatically check for missing packages during build in Visual
Studio: controls automatic restore by changing the
packageRestore/automatic setting in the NuGet.Config file as shown
below (%AppData%\NuGet\NuGet.Config on Windows,
~/.nuget/NuGet/NuGet.Config on Mac/Linux). When this option is set,
running a build from Visual Studio automatically restores any missing
packages. The option does not affect builds run from the command line
using MSBuild.
I am using Visual Studio 2017 and pull the source code from TFS server, then build the solution, I got the following error:
Microsoft.Common.CurrentVersion.targets (3863,5): Error MSB3113: The
file "SqlServerTypes \ x64 \ SqlServerSpatial140.dll" was not found.
Then I found this dll file comes from the nuget package sqlserver.types, as I know, Visual Studio will restore the nuget packages when we build the solution.
Why I still have this issue?
File was not found after nuget restore
When you download the nuget package Microsoft.SqlServer.Types from the nuget.org and open it with nuget package explorer:
You will find the sqlserver.types nuget package not only includes .dll from .net framework, but also has native binaries files. These files are designed with x64 and x84, they could not added to lib folder directly. So the package owner adds them to project as content. However, these dll files is setting to ignore by default for TFS, you need to add them manually.
Of course, you can also use the command line Update-Package <package_name> –reinstall to reinstall this nuget package, but this requires you to execute this command every time after you pull the code from the TFS server. Add this native binaries to the source control will Will reduce these unnecessary troubles.
Hope this helps.
You can try this:
Update-Package <package_name> –reinstall
I have a VS solution and as part of a TeamCity Build, we restore packages from both a private NuGet feed (myget) and the public feed (nuget.org). Most packages restore fine, but it hangs on the ones below for WebApi and Mono.Security. This is all working locally in Visual Studio.
[restore] NuGet command: C:\TeamCity\buildAgent\plugins\nuget-agent\bin\JetBrains.TeamCity.NuGetRunner.exe C:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe restore C:\TeamCity\buildAgent\work\953bd084b49f7d88\DataFinch.Web.sln -Source https://www.myget.org/F/datafinch/auth/<hidden>/api/v2 -Source https://api.nuget.org/v3/index.json
[11:41:35][restore] Starting: C:\TeamCity\buildAgent\temp\agentTmp\custom_script473789219385667038.cmd
[11:41:35][restore] in directory: C:\TeamCity\buildAgent\work\953bd084b49f7d88
[11:41:35][restore] JetBrains TeamCity NuGet Runner 8.0.37059.9
[11:41:35][restore] Registered additional extensions from paths: C:\TeamCity\buildAgent\plugins\nuget-agent\bin\plugins-2.8
[11:41:35][restore] Starting NuGet.exe 2.8.50926.602 from C:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe
[11:41:43][restore] Unable to find version '5.2.3' of package 'Microsoft.AspNet.WebApi.Client'.
[11:41:43][restore] Unable to find version '5.2.3' of package 'Microsoft.AspNet.WebApi.Core'.
[11:41:43][restore] Unable to find version '3.2.3.0' of package 'Mono.Security'.
[11:41:43][restore] Unable to find version '6.0.4' of package 'Newtonsoft.Json'.
[11:41:43][restore] Process exited with code 1
Teamcity config:
Try using https://www.nuget.org/api/v2instead of https://api.nuget.org/v3/index.json per the nuget docs: https://docs.nuget.org/consume/Command-Line-Reference.
The reason why the build failed, was an old version of nuget.exe. I finally solved this problem by downloading the latest version and put this executable in the Program Files x86 folder. Then I created a new system variabele to point to this executable. After that I add a NuGetInstaller package in my TFS Build Definition to let me configure TFS using this new NuGet.exe.
This link helped me to let TFS use this new NuGet version
I followed this: https://blogs.msdn.microsoft.com/tfssetup/2017/04/18/tfs-2017-update-1-nuget-restore-task-always-fails-trying-to-find-packages-even-though-they-exist-on-the-feed/
I had tried 3.3 and got this error:
Restoring NuGet package Microsoft.AspNet.WebPages.3.2.3.
WARNING: Unable to find version '3.5.0.2' of package 'Antlr'.
I downloaded the latest NuGet 4.3.0.4406 and set the Custom path to NuGet and that failed as well.
Surprisingly when I switched to 3.5 it worked.
If you are really stuck, run the command in a Command Line Prompt and it will work:
C:\Program Files (x86)\NuGet\nuget.exe restore -NonInteractive E:\agentXYZPool\_work\1\s\xyz.sln
I ran into this problem with one of our build slaves leveraging TFS and Visual Studio.
The way I fixed it was, I opened the solution that wasn't compiling in Visual Studio, right-clicked on the SLN and selected "Enable Restore NuGet Packages"
That prompts a dialog box that you have to accept. After you've done that, you might be good to go. Right-click on the SLN again and run "Restore NuGet Packages", and if that operation succeeds, you're golden.
There's probably some setting you can adjust programmatically when setting up your slave environments, but that's one direct way to fix this kind of problem.
According to THIS current document as of this writing from MS, the proper url is: https://api.nuget.org/v3/index.json
So I went about to fix the issue because I assumed it had nothing to do with the URL. I did 2 things, not sure which it was that resolved the issue but I'll post both here in case it helps someone.
Within TFS2018 and within my build step for the installation of Nuget I specified version 4.9.3 (the reason I chose 4.9.3 because I noticed by looking at detailed log of VS that during my build it was using this version) and chose to always download the latest version.
Second thing I did was I removed a Nuget.Config file from my project that was left over from something I was testing. Then I re-commited my changes to TFS
After I did both of the above steps the rest of my build started working.
Using an old version of Visual Studio's Nuget
Visual Studio has C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\Nuget.exe. Jenkins was using that to nuget restore
Updated Nuget in program files,
C:\Program Files (x86)\NuGet> ./nuget.exe update -self
Pointed Jenkins at that new Nuget path and 🔥cooking with gas🔥
SET PATH=%PATH%;C:\Program Files (x86)\NuGet
nuget restore SolutionName.sln