I was wondering about the right way to do this. For example, let's say you have a number of projects (part of a solution) that uses boost. Let's say you want to put the boost package in the solution so the entire thing is more portable.
How do you do that? Do you install boost in a directory within the solution? Can you reference it using relative directories, so it isn't portable?
Under Linux, for completeness, one could just store a tarball in the code under control, but it was left to the developer to bring it out and install it. I'm wondering how this is done (best practices) under visual studio.
[NOTE: I understand this might make the solution large, but the benefit would be a development environment that would run immediately without a bunch of package installs for each development system accessing the code.
In this case you could use the nuget package manager in visual studio to add the nuget boost package to your solution then boost will be available to the projects that need it. You can then enable package restore so that whenever the solution is built if the boost files are missing from the solution then nuget will restore them on build.
If you haven't already you will need to install the nuget package manager plugin for visual studio.
Where the package isn't available on nuget there are a number of options; you can build the package and then reference the assembly that's been built - you just store assemblies you need in a references directory. If your using source control software Svn or tfs possibly git ( I don't know) then you can store these in source control and then include them in the target solution via links. The final option I can think of is you can build the package into a nuget package and then store the result in your own private nuget store visual studio allows for this. Which solution works for you will depend on the size of the project, development team and the source control software you use.
Related
One of my vcxproj's (with a vcpkg.json) looks like this
And another one (with a vcpkg.json) looks like this. Note the missing option.
But I need to be able to enable the vcpkg Manifest so it can compile! I'm stuck, where did this option go? Both proj's are in the same solution. Both have vcpkg.json added to their Source Files. Notably one has a different dir structure (proj/proj.vcproj vs proj/build/proj.vcproj) so the vcpkg.json is further away
As a design note, conditionally hidden options or grayed-out options are an anti-pattern.
A vcpkg.json alone is not enough. vcpkg needs to be enabled in your proj.vcproj file.
Try the following steps:
Close the solution
Open the proj.vcproj files in a normal editor
Look for the VcpkgEnableManifest and other vcpkg properties in there.
Better still, use WinDiff or a similar DIFF tool to discover the differences between the vcproj files.
I cannot be more specific because you didn't say how you imported/integrated the vcpkg options into your project in the first place. There are many different ways to do that.
For example, I am using the vcpkg export --nuget command to export a nuget package, which I then add to my individual projects with the Visual Studio nuget package manager. This will import "vcpkg.props" from the nuget package directory. This import command adds the options you are missing. If you are using the same method, you probably forgot to add the nuget package to your other project. This way of integrating vcpkg is "per project" rather than globally, so it does not matter if the two projects are in the same solution or not.
If otoh you used the vcpkg integrate command to integrate the vcpkg globally, things will be different. In this case the import command will be inside some Microsoft.props file and the options should appear in all projects.
Okay, I found out how to fix it. I had gotten myself in a corrupted state by unloading and loading VS projects while VS was open AND while running vcpkg integrate project/install commands.
I misunderstood those commands. I thought vcpkg integrate project installed MSBuild vcpkg just for that project so I thought I had to run that for each .vcprojx.
Rather, vcpkg integrate project may be better named vcpkg integrate nuget and vcpkg integrate install could be named vcpkg integrate msbuild?
In any case, the fix was to close all instances of Visual Studio (I even uninstalled extra versions), and just run vcpkg integrate install ONCE and then reopen Visual Studio. Then it worked.
I have a list of nuget packages that I only use for development. I know in node you have devDependencies. Is there a similar way in visual studio? What's important for me is to control which packages gets carried over to production.
My team mate figured out the solution to this which is using conditional assembly reference. So the package will still be restored when the package is build but it won't be included in the deployment of the final build.
https://heejune.me/2016/02/17/c-conditional-assembly-reference/
We have a set of functionality that was previously in a regular dll file, but that is now in a Nuget package. Naturally, we want to pull it using Nuget instead of having to download and update the dll:s manually. All projects are handled in VS 2013, so we have access to it through the package manager.
Now, we need to go over all the projects in the source tree to update the reference to be a nuget reference instead of the old dll reference.
You can do this on a solution level using the package manager, but since there are several dozens of solutions and well over a hundred projects I'd rather not do it manually.
Is there a way to automate this? That is, to iterate through the source tree, find every .sln file and update the references in its underlying project files?
You can probably do it by writing a small C# program. Install NuGet.Core and NuGet.VisualStudio package to the program to use functions in nuget.core.dll and nuget.visualstudio.dll, plus some DTE functions.
I'm working on a TFS project with a small team. This project has a bunch of nuget packages installed, but it's for a 4.0 project, and the nuget package manager GUI doesn't even offer the older versions of the packages any longer since their 4.5 equivalents are now being used. In order to allow other team members to compile the project, they need to have the exact versions of the packages. I'd like to check in the entire "packages" folder used by nuget. Is this a good idea? If so, how does one check in the "packages" folder and all its contents since it exists at the solution level? There is no "Include in Solution" option in Visual Studio as there is when you right-click an assembly.
in the past I have also checked in the NuGet packages into version control. With this some problems appeared:
Some packages where not checked into version control when committing from Visual Studio into TFS.
Updating packages became a real problem.
For the first problem I had used the TFS Power Tools. The problem with this solution is that every developer needed to install the Power Tools.
A better solution came up with NuGet 2.7. It introduced package restore. With package restore there's no need to check-in the packages folder. They will be restored during build.
We use an on-prem TFS install with no internet access so we have to check in our package folders or our builds fail. The biggest issue is that VS does not behave consistently when it comes to adding the pending changes for new package files, often times it will ignore the .dll files in the pending changes window, sometimes it adds everything fine.
I've added some libraries to a VS 2010 solution using Nuget (RestSharp, Twilio, etc.). When I pull the same solution down to a new PC from TFS and try to build it, all the references to those assemblies are broken (error "namespace cannot be found..."). Is it necessary for each developer who works on this VS solution for the first time to independently install the same Nuget packages on their PCs?
Thanks,
Jim
As Andrew already have said it's all about the packages' location.
Either you have to check in the entire packages folder with all the packages, or each developer have to install the packages after first checking out. But there is a better way to do this, namely to use NuGet Package Restore - which will automatically install all missing packages when the project is built.
If you use package restore, you only need to check in the repositories.config into your VCS. With TFS you can cloak the entire packages folder except for the repositories.config, so that TFS doesn't annoy with pending checkins for new packages.
Also see this answer for guidance on how to use TFS + NuGet.
No, but you need to be sure the assemblies are all included in the same relative path so Visual Studio can find them. You can include the solution's nuget packages directories, which is where I think it stores a copy of the libraries to be referenced by the project(s).
Incidentally, including said diretories may be effectively the same as "installing the packages". If you include all the files that NuGet uses in its management of packages, NuGet will behave the same as if you had installed them. But you don't need to do the actual package install via NuGet for it to work... or even have NuGet installed in Visual Studio in the first place. It's just a matter of the proper files being where the Visual Studio project files expect them to be.