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.
Related
I am currently working in a UFT project, using the VBScript language.
This project does not have a .sln or even .csproj files, because of this i am using the nuget.exe.
I want to use NuGet to manage binaries. I am already able to push a NuGet package to the repository, however I can not update or install it.
This is how my project looks like(I know its a bit different and is located on c:):
So it happens that I searshed on the internet but there are not even one project that looks like mine, most of them are done on Visual Studio.
Could you help me on how to use NuGet in a project like this one?
Thanks!
I want to use the https://github.com/FaceDetect/cnn_face_detection project stored on Github repository but it shows so many different files and no proper documentation is available. Can anyone tell me how to build that github project into an executable?
If the github project has releases or tag, like tornado releases on github.
Then you can run
pip install https://github.com/project_name/archive/version.tar.gz
like this:
pip install https://github.com/tornadoweb/tornado/archive/v4.3.0.tar.gz to install the github online project.
But when the project does't have release tab. You need clone the project and compile from source.
In most cases, you can run python setup.py install.
The question has a python tag. So take python project as an example.
GitHub is mostly used for code. in various languages
How to make any github project usable or executable is specific to the language and to the kind of the project itself.
Also it need to be careful with the license terms, the state of reliability and completeness of the project you intend to work on (i.e: github.com/leezivin/FaceDetection_CNN – snakecharmerb); The fact that the specific project you mention, at the time, do not have a README.md and a license file jet , let's suggest to contact the author or someone contribute/commit the sources for any further informations.
btw the project you mention appears to be a c++ language project; so you need to be able to compile and link it ( Clean an Rebuid ) in some form of executable; The specific repo: cnn_face_detection contains Visual Studio solutions and projects therefore the easy way could be by using Visual Studio and open/import the artifacts ( it depends by version of visual studio you eventually can use ).
It is also required:
to choose if you intend to trust ( or not to trust ) the code:
to take care to the paths of the dependencies referenced by the prj because likely they need to be changed to the actual paths were you clone ( download ) the sources on your own filesystem. if don't do that you may not be able to compile the solution (i.e the three projects contained in the repo ):
By looking around the project, you will find folders named "VC2010" and "VC2006". This is a good clue that this is a Microsoft Visual C (or Visual Studio) based project. Inside you will find .sln and .vcxproj files, which are "solution" and "project" files, according to this list
Download and install Visual Studio from here. There are several options, try the Community edition first.
Download the source code of the project from github. To keep it simple you can just use "Download ZIP" button on the project home page.
Run Visual Studio and follow these directions to open one of the solution (.sln) files:
On the File menu, click Open Solution. The Open Solution dialog box opens.
Navigate to the solution you want.
Click the solution folder, which displays and selects the solution file within the folder. If no solution file is visible, verify that the value in the Files of type list box is Solution Files.
Click Open.
Build using these instructions. At this point you either have an .exe or a .dll (depending on which project you're building).
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.
When other developers get the vs.net 2013 solution from TFS, Nuget doesn't seem to work as expected and many of the individual projects in the solution do not have the required dll's downloaded (although they are defined in the packages.config file).
If I go to view the installed packages, it shows up as they are installed and the correct projects are selected.
I went into console and ran:
Update-Package -Reinstall
After doing this, my packages.config file was truncated for whatever reason and 80% of my packages were removed from the config file!
What should I be looking into as it is either I have setup the solution incorrectly or nuget just isn't reliable.
Thoughts?
First of all make sure that NuGet Packages Restore is turned ON.
This forces to restore missing binaries directly from NuGet server. You can right click on Solution and enable this option as follow:
Make sure that .nuget folder that contains nuget.exe is created under your Solution.
You'll want to make sure that you have automatic package restore turned on in VS 2013. You can do this in the options.
Then, when you build, VS should grab the packages for you. If you want to manually restore the packages or do it from powershell, you'll want to use the command nuget.exe restore in the folder your solution lives in.
If you're using custom package sources, you'll want to make sure you specified them in your nuget.config file.
With newer versions of NuGet it is possible to configure a project to automatically restore NuGet packages so that the packages folder doesn't need to be included in the source code repository. Good.
However, this command adds a new .nuget folder and there is a binary there, NuGet.exe. This can also be re-created automatically by Visual Studio and so it doesn't feel correct to add that to version control. However, without this folder Visual Studio won't even load the solution properly.
How do you people deal with this? Add .nuget to source control? Run some command line script before opening the solution?
This post is old, you should not be using solution level NuGet package restore anymore. As of version 2.7+ there is an option in the NuGet setup to automatically restore packages on build.
So the .nuget folder can be deleted and the option removed from your projects.
http://docs.nuget.org/docs/reference/package-restore
UPDATE: With the release of NuGet 4.x and .NET Standard 2.0, when you use the new csproj format you can now use package references, ironically reintroducing the dependency on msbuild to restore packages, but now packages are a first class citizen of msbuild. The link above also makes mention of the PackageReference, but the following announcement details it better:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
And the NuGet 4.x RTM announcement, which ironically isn't as useful:
https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html
UPDATE 2: Apparently with VS2017 you can even use package references with classic csproj projects, but they aren't backwards compatible anymore, and there have been some problems with restoring package sub-dependencies. I'm sure that will all be resolved.
#Richard Szalay's answer is right - you don't need to commit nuget.exe. If for some reasons Visual Studio does not automatically download the nuget.exe, make sure you have the following set to true in the nuget.targets file:
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>
Close the VS solution, reopen it and build it. Visual Studio should download nuget.exe automatically now.
According to this thread, the .nuget folder should be version controlled.
You need to commit .nuget\nuget.targets, but not nuget.exe. The targets will download the exe if it doesn't exist, as long as you change DownloadNuGetExe to true in nuget.targets
Although I usually don't like the idea of adding exe's to source control, I would suggest that source control should contain anything that is required in order to open, build and execute the project.
In this case it sounds like the .nuget folder is a required dependency. Therefore it ought to be under source control.
The only question left, that you need to research, is how NuGet is going to react if that folder is marked read-only, which TFS will do once it has been checked in.
Update:
I did a little more research on this as I've never used NuGet before. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
I would suggest that probably what you want to do is make NuGet a requirement that has to be installed on every developers workstation.
Further, you should place in source control the batch file required to get a workstation ready to start editing the project. The batch file is going to run the commands necessary to get and install the dependency packages.
Beyond that I'd say you might want to contact NuGet directly to ask them how, exactly, this is supposed to work.
Now that nuget supports package restoration we're looking at it more closely.
We use Subversion for source control, and my initial thoughts are that .nuget should be added to our repository, but added using svn:externals so that it points to a single location.
That way we can automatically push out new versions to all developers and projects. For projects on release branches, rather than HEAD, we can specify the revision of svn:externals reference if we want to leave nuget alone.
We have a lot of projects, so it also means not duplicating nuget.exe multiple times in the repo.
We have the nuget.config file in the folder, as it has the references to our internal Nuget server, using the Package Sources area:
https://docs.nuget.org/consume/nuget-config-settings
Apart from this reason, you should let Visual Studio handle the downloading of packages.