I have a Visual Studio 2022 solution containing dot net 6.0 and clr:netcore projects.
Most of the projects depend on other projects as a reference using dependency injection (not project reference).
I need to create NuGet packages for all projects separately.
Is there any way, rather than writing a script, to do it at once?
What i am thinking of is having a separate .nuspec file for each project and running a script to create packages with dotnet pack command.
Anyone have such an experience?
Related
I am adding unit tests to an existing C++ Visual Studio projects, using the Google Test adapter.
It's all running fine on my computer with Visual Studio 2019, but when I try to run them on the build server I get the following error
error : 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 ..\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.3\build\native\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.targets.
However, we're not using NuGet for package management. I tried installing it but complained about missing folders. This is not a .NET project, so I think that's a red herring.
I was able to install the Google Test adapter on my computer using the Visual Studio Installer, but it does not show up as a part of the VS Build Tools on the build server.
Running msbuild -t:restore does not help, it just reports "nothing to do."
I don't understand why the Google Test adapter isn't available for VS Build Tools, since it seems to be required in order to build the unit tests. Does anyone know why it doesn't work? What's the best practice for handling this?
Thanks!
The problem is that your c++ project has missed the content of googletest nuget package. So the solution is to restore the whole nuget package in your c++ project.
Update 1
First of all, take a brand new backed up project and restore it to when the problem started.
Besides, msbuild -t:restore command applies to projects with PackageReference nuget management format.
Since your c++ project used packages.config nuget management format, msbuild -t:restore will not work. See this official document.Instead, you should use nuget restore command.
This command works for your current project and running this command will restore the nuget packages and then you will never face the issue.
Before using it, you should download nuget.exe CLI and config its path into System Environment Variable PATH so that CMD can invoke nuget.
The steps about configing nuget.exe, you can refer to this link.
Steps
1) delete packages folder under the solution folder
2)Then, open build tool, run:
nuget restore xxx\xxx\xxx.sln(the full path of solution file containing the c++ project and the unit test project)
Then, you can build the project with the command. And I hope the error will disappear.
We switched to NuGet to manage our packets in Visual Studio 2017, everyathing works fine now but to push the packages you need to first create a nuspec, create a nupkg (NuGet Package) and then push it to our NuGet Server.
All of this commands get some parameters of which some would stay the same and others need to get from the visual studio variables.
Can you recommend any scripting language that would work for this or have any other solutions for this?
Btw im a "newbie".
Can you recommend any scripting language that would work for this or
have any other solutions for this? Btw im a "newbie".
1.Since we can pack packages from xx.csproj, you can use command like nuget pack xx.csproj to create nuget packages. After that, you can use nuget push command to publish them. To push several nuget packages the same time use command like nuget push path\*.nupkg -source .... You can get some help from this link. Note if you've had the same package with same version in server,it won't automatically overwrite it. (And you can include them in a batch file like this)
2.You can try CreateNewNuGetPackageFromProjectAfterEachBuild package, install this package to your project, and it will create packages automatically for you after each build. So you don't need to manually pack them by command.(Works for my C# .net fx project).
3.For .net core projects, if you right-click the project in Solution Explorer, you can find the Pack button. After build your project successfully in VS, use the pack option will automatically package your assembly.
4.Also, assuming you're in a solution with many class library projects and you want to pack them, you can follow this document.For .net framework projects using packagereference format, add the NuGet.Build.Tasks.Pack package to the project dependencies. After that, you can use command like msbuild -t:pack xx.sln to pack all projects whose GeneratePackageOnBuild property is true.
Most of above are about how to pack packages easily. And after you get the output xx.nupkgs, nuget push *.nupkg -Source... can help you do the publish job.
I'm currently looking for a way to trigger a NuGet update on build in Visual Studio 2017.
I'm using VS2017 Pro. My codebase consists of multiple solutions which break the code into layers (data access / business logic / ui / application / etc). When a solution builds, it generates one or more NuGet packages which are then consumed by projects further up the 'food chain'.
Automating the NuGet update on our build server is trivial, however it would be nice if we could configure our development environments such that it always attempts to get the latest NuGet packages on build akin to how Package Restore works.
I've come across a lot of information regarding older versions of Visual Studio/NuGet that include updating the auto-generated nuget.targets files, however these aren't created in VS2017 with NuGet package manager 4.6.x (unless I'm doing something wrong!)
Any help or advice would be greatly appreciated.
NuGet Update on build (VS2017 Pro)
If pre-build events are too late for you, you can try to add a new project to the solution with pre-build event/post-build event to update the nuget packages, which uesd by other projects/solutions:
<YourNuGetPath>\nuget.exe update "<YourSolutionPath>\xxxx.sln"
Or
<YourNuGetPath>\nuget.exe update "<ThePackages.configFilePath>\Packages.config"
In this case, you can build this new add project to get latest NuGet packages for these projects/solution using nuget packages.
Besides, if you do not want to build this project before those consuming nuget package projects, you can let those projects reference this new add project, Visual Studio will build it before building those consuming nuget package projects.
Hope this helps.
To date, using Visual Studio 2015, NuGet packagas are restored into a solution-specific "packages" folder, which I check in to source control. Our TFS Build server does not have Internet access, so it needs these local copies to successfully build.
I am now trying out Visual Studio 2017, with a .NETStandard Class library, and it no longer makes a local copy of NuGet packages - instead they appear to be stored in %HOMEDRIVE%%HOMEPATH%.nuget\packages. This means they are no longer available on the Build server.
How can I get NuGet to store packages locally?
You should be able to define a RestorePackagesPath property in your .NET Standard (SDK style) project which defines where the NuGet packages should be restored to.
You can use this to tell NuGet to not use the .nuget\packages directory but instead use some other directory relative to your project.
<PropertyGroup>
<RestorePackagesPath>..\path\to\MyPackages</RestorePackagesPath>
</PropertyGroup>
Looking at the NuGet documentation they mention three possible approaches when using a project that uses PackageReferences.
Set the NUGET_PACKAGES environment variable to a different folder.
Create a NuGet.Config file that sets globalPackagesFolder to a different folder.
Specify a different folder with the RestorePackagesPath MSBuild property.
I have an ASP.Net project that's using the ClearScript.V8 library which relies on the Visual Studio 2012 C++ Redistributable to work. I'm faced with the prospect of having to install this on 50+ machines and I'm curious if I can get TFS to do it for me.
I realize this straddles somewhere between Stack Overflow and Server Fault so I'm asking on both sites.
Assuming that the binaries for ClearScript.V8 is included in your project (either as files copied to the bin folder or as a NuGet package) you should be able to also include the necessary Visual C++ redistributables files as binary files in your project. They will then be stored in TFS.
If you prefer NuGet packages you can to set up a local NuGet repository within your organization and create a NuGet package with the necessary DLLs which you then can reference from your project. If NuGet package restore is configured for your solution the package will be downloaded before the solution is built. In VS2012 you will have to make some customizations for this to happen on a Team Foundation Build server.
If you are unsure which DLLs you need to include you can use a tool like Dependency Walker to discover which DLL's are required, or you can debug the application and see which DLLs are loaded in the modules window. Microsoft has some information which DLLs to redistribute.
If you are having problems with conflicting versions of a redistributable DLL getting loaded you can create a side-by-side manifest to ensure that the correct DLL version is loaded into your application. However, as your application is hosted within ASP.NET this is somewhat tricky because w3wp.exe is executed by IIS outside your direct control. You will have to create an activation context to configure the manifest used by your application.
If you need to have things installed on your server for a build I would recommend that you use Chocolatey.
chocolatey.org/
This is an implementation of NuGet in PowerShell to explicitly solve the issue that you face. You can create a powershell file that installs all of the bits that you need and easily include it as a pre build step in TFS 2013. You can use the PowerShell activity from the TFS Community Build Tools to call the PowerShell in TFS 2010 or 2012.