If I want to keep backups of my code and I don't want all the libraries and nuget libraries in the backup, how do I do that?
I run clean on my solution and I noticed there are still DLL's and EXE in the bin and obj folders. Ok, I can delete those folders manually. I can delete the package folder which will remove all the nuget libraries, but if I ever want to restore, will my solution redownload all the nuget packages needed for the project? I'm afraid to test that theory and from what I read there is meta data and other things in the package folder will will cause me problems. If I zip what I have after deleting bin and obj folder, the zip is 450MB. If I go into the zip and delete the package folder, I see it is only 25MB. It seems to be all in the Package folder. From an ReactJS perspective, I can do a build and it cleans all this out and when I want to reimport for an existing project, I run a install. Is there not something like this for Visual Studio 2017? Will I be able to recover easily if I just delete the package folder before I back it up?
If I want to keep backups of my code and I don't want all the
libraries and nuget libraries in the backup, how do I do that?
Which way do you backup the code? According to your description, it seems you're trying to zip the solution and store it somewhere to do the backup. If so, you can delete the bin, obj and packages folders before you zip the solution. (You can even delete the .vs folder)
Is there not something like this for Visual Studio 2017? Will I be
able to recover easily if I just delete the package folder before I
back it up?
There're two ways to manage nuget packages in VS, packages.config and PackageReference format. Since you have packages folder in your solution, I think you use packages.config format. The info about nuget packages your project consume are defined in packages.config and xx.csproj file. After you delete the packages folder, you can easily recover the packages with the help of the packages.config file and xx.csproj file.
Import the solution which you've deleted bin, obj, packages folders in VS, right-click the solution in Solution Explorer and choose Restore nuget packages option, then it will help install the packages your solution need according to your packages.config file. So the answer is Yes for Will I be able to recover easily.
In addition:
1.When you install one nuget package, it will firstly install it in global-packages folder, and then copy them to your solution. So in same machine, if you zip the solution before delete the packages folder in solution. When you recover, it will first look for the cache, if the cache doesn't have the required nuget packages, it will install them from package source.(like nuget.org). You need to enable these two options in VS setting.
2.If you're using PackageReference format, the packages are stored in %userprofile%\.nuget\packages but not in your solution. And you can easily recover the packages though you zip the solution and copy it to remote server.
3.Apart from the restore nuget packages option in VS, you can also use command-line like nuget.exe, msbuild.exe... More details see here.
Why not just use some source control to do just that?
If you use Team Foundation Server with TFVC or Git it will do just that. You will have all your code under version control, without dll´s, bins, build artifacts, packages or anything. Without all those heavy, innecesary things that can be recreated by just rebuilding the solution again.
And of course you will enjoy all the advantages of having your code under source control: namely, not only having a backup of your code, but of all changes it has undergone with thus far.
Just saying.
Related
I'm working on a solution (C#) with 3 projects in it (one library and two applications) and I wonder what is the bare minimum of files you need to commit to be able to pull off a fresh solution and get it to work right away?
Obviously all source files, *.sln, *.csproj are needed and not the obj folder or bin folder (unless I want to keep a working copy of the compiled files).
But do I need to commit the:
Properties folder
.vs folder
*.resx
*.config
I have Googled it but all I found was a list of the file types, but no explanation of what files where critical to make the solution/project load and compile.
[EDIT]
It has been suggested that this is the same question as: Should I add the Visual Studio 2015 .vs folder to source control?
The question is not related to only the .vs folder, but to all project/solution files.
Though SVN and Git are different Version Control System, I think the files that should be excluded in the Version Control System should be similar. This file is a ignore file for Git (an .gitignore), but should be work as it should in SVN Version Control Systems.
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
This file is often used in various places like Github Destktop, or the Github Site itself.
I've got a Visual Studio 2017 solution with several C# class library projects. On disk they take this structure:
MyProduct
MyCompany
MyCompany.ModuleA
MyCompany.ModuleB
MyCompany.ModuleC
But when I look at them in the "Manage NuGet Packages for Solution, the checkboxes show up in the dialog inconsistently. ModuleC appears strangely. Like this:
MyCompany.ModuleA
MyCompany.ModuleB
MyProduct\MyCompany\MyCompany.ModuleC
Also, whenever I build Module C, it keeps creating the following 3 files in its output /obj folder
- MyCompany.ModuleC.csproj.nuget.g.props
- MyCompany.ModuleC.csproj.nuget.g.targets
- project.assets.json
Neither of the other two modules does this.
I'm trying to understand the reason for the inconsistency and to fix it if I can. I have tried combing through the text of the .csproj files for these various projects but I can't spot any differences that might make this happen. And the raw text of the .SLN file project entry all look consistent for each of the 3 modules.
How does NuGet decide what name to put in the Manage Packages for Solution dialog?
Why is NuGet creating those temporary files in the output folder for Module C but not Module's A or B?
How does NuGet decide what name to put in the Manage Packages for Solution dialog?
It is depends on the NuGet manager type, packages.config or PackageReference.
If the project use packages.config, project name will be put in the Manage Packages for Solution dialog. If the project use PackageReference, project file name and relative path will be put in it. That because NuGet will update the project file .csproj when we install the nuget package with PackageReference. So, in the the Manage Packages for Solution dialog, it shows the relative path+project file name, like ClassLibrary1\ClassLibrary1.csproj.
Why is NuGet creating those temporary files in the output folder for
Module C but not Module's A or B?
That because NuGet with PackageReference controls the msbuild items that are generated for these files into the obj\projectname.csproj.nuget.g.props, obj\projectname.csproj.nuget.g.targets and project.assets.json file.
You can unload your project, check if the project file MyCompany.ModuleCuse the PackageReference, like:
<ItemGroup>
<PackageReference Include="Newtonsoft.Json">
<Version>11.0.2</Version>
</PackageReference>
</ItemGroup>
For some more details, please check this official blog: NuGet is now fully integrated into MSBuild.
I have a cmake project that builds fine on Linux and that I want to build also on Windows. The code is portable and is made of C++ so... it should build. The only thing is that, on Windows, I need to use nuget to restore some packages, cpprestsdk is one of them. Now when I run
cmake .
CMake will generate solution files and projects files that I don't want to include in my VCS at all. The thing I want MSBuild to do is to apply the packages contained in my packages.config to all the project files found in the project directory.
Anyone knows how?
The thing I want MSBuild to do is to apply the packages contained in my packages.config to all the project files found in the project directory. Anyone knows how?
I am afraid you can not do such things. That because whether you are using MSBuild or NuGet to do this thing, you have to use to the nuget.exe to do it. However, install nuget packages to the project file relies on VS capabilities not nuget.exe and nuget team not plan to bring it to the exe.
The NuGet Command Line does not actually install any packages. The install command is actually doing a restore operation.
This means that nuget.exe install will only download and extract the package into the output location. It will not modify the project file. Although, the package manager console seem to offer "Install-Package" for doing this, but you have to open each project files with Visual Studio and execute Install-Package in the package manager console for each project files, which is not what you want. So you could not enable this script outside of visual studio.
So we could not use MSBuild to apply the packages contained in the packages.config to all the project files found in the project directory.
You can refer to this thread and this thread for details.
Hope this helps.
My setup is rather simple: MyGet pulls my repo from GitHub on commit and builds. I then manually push the successfully built project to NuGet.
The version is manually set except for the build counter. Is there a way to pull the version from the AssemblyInfo, .csproj file or somewhere else?
I've read the docs and the only thing I can find is using GitVersion and a build file. I'm hoping there's a cleaner/simpler way, e.g. %project_version% :)
By definition, a build counter is managed by the build system and can only be reset at best.
To use the version from AssemblyInfo.cs as the NuGet package version, you could create a .nuspec manifest next to your .csproj file (give it the same file name only differing by extension), and use the $version$ placeholder.
I've got a blog post that explains this in further detail: https://www.xavierdecoster.com/post/2012/04/26/nuget-version-token-explained.html
i am currently trying my first steps with nuget package manager (3.4.3.855) in VS 2015 (Enterprise). For my C++/Qt project i managed to find some libraries i need and they seem to be correctly downloaded to <myprojectDir>/packages/<package_name>/... folders.
However, it is a mystery to me, where and how include folders for headers and/or libs are specified for the project?
I mean, for example with the Eigen library, after importing the nuget package i can just #include <Eigen/core>, which is located in
<myprojectDir>\packages\Eigen.3.2.9\build\native\include
and everything works fine, but i neither have the packages\Eigen.3.2.9\build\native\include-path popping up in the VC++ Directories->Include Directories list in the property pages nor is there a custom property page in the project properties (yes, i did not click the solution properties ;) ) as seen e.g. in this example video with the zlib package. I do not even have this property page if I install the zlib package.
While it seems to work somehow under the hood for Eigen, it does not for the Visual Leak Detector (vld) package... so knowing how things work would be great ;)
Thanks for any help...
From NuGet 2.5, C++ project recognizes the installed packages through MSBuild properties and targets files from NuGet package. After installing packages in C++ project, the MSBuild files are imported into your project file. So the projects will know how to find and use the contents of the NuGet Packages.
To make MSBuild integration better, NuGet has created a new convention for automatically importing MSBuild properties and targets from a NuGet package. Alongside the existing \content, \lib, and \tools folders, NuGet now recognizes a new top-level folder: \build. You could open the Eigen package that you have installed through NuGet Package Explorer, there has a \build folder and a Eigen.targets file which contains MSBuild properties.
Please refer to the MSBuild Integration part from below link:
http://blog.nuget.org/20130426/native-support.html