Does anyone have any recommendations of Visual Studio extensions that can be used to add projects to a solution that generate a NuGet package. Ideally, we would like something where we could tell it the relative path of the contents, and one that supports pushing symbol files as well.
There is the NuGet Packager Extension created by Ove Anderson.
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 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.
I have a project with a few front-end frameworks obtained via and managed by Nuget (Twitter Bootstrap, jQuery, jQuery UI ...).
I want to keep the files in my project, but remove them from Nuget's grip (I don't like the way Nuget organizes these files).
When I un-check the project for a library Nuget removes all the files it had installed, unless I've editted them (e.g. I over-wrote bootstrap.css with a customized version from getbootstrap.com).
As I do this from time-to-time, instead of backing up the /Content and /Scripts directories and adding back in the relevant files after removing the library from Nuget, I'd like to be able to dissociate all files of a particular library from Nuget at once without removing them from the project's directories. Is that possible, by either the GUI or the console?
I don't know if this issue is specific to a version(s) of Visual Studio, but mine is VS 2012
Can you elaborate for the part of "I don't like the way Nuget organizes these files"? If you remove NuGet from the picture, the good things that it does for you (detection of package updates, automatic package restore etc.) will be gone.
If you absolutely need to do this, one possible hack would be deleting packages.config from the project.
I have a solution with two projects:
.NET application
WiX setup project.
I know, that it is possible to refer to project output in WiX source ($(var.WindowsFormsApplication1.TargetFileName)).
Now I've added a NuGet package reference to my .NET application. So, I want to bring NuGet package content into my setup.
Is there any way to do this instead of adding files manually?
I don't believe there is any linkage. I know what nuget is but I haven't used it much because it's more about brining your .NET dependencies into scope then software distribution. Depending on how nuget lays the files down you might be able to do something like $(var.SomeProject.TargetDir)nuget_fetched.dll.
This is assuming that SomeProject uses nuget in such a way that the references are copied locally and available in the Outdir of the project.
I wrote a Resharper live template to cut out a lot of the typing involved in adding the files, but essentially I've just added the files manually. Creating a Wix component per nuget package keep things neat.
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.