I'm working with ASP.NET MVC 4 in Visual Studio 2010 for the first time, and I control source code with SVN. I used to work with MVC 1 in Visual Studio 2008, where I had my own filter for svn:ignore
*.pdb
*.exe
*.dll
debug/*
release/*
*.user
*.suo
obj/*
bin/*
obj
bin
VSMacros80
Thumbs.db
_ReSharper.*
but it doesn't apply in the same way now because the project has some new folders, as the packages folder, and I don't know which of them must be versioned.
About the packages folder, should I include it the repository or this folder must be ignored? What other folders or files should I ignore?
It sounds like you are using NuGet and the packages folder is the NuGet packages folder. You can commit this to source control if you do not mind adding several large but infrequently changing binaries.
Alternatively, you can omit it from source control and configure NuGet to download packages on each build if developers and the build machine are to download it as required. This also runs the danger of someone downloading a newer version and causing conflicts.
As for other files to exclude form source control, see What .net files should be excluded from source control? and For a .Net project, what file extensions should I exclude from source control?.
Related
Let's say I have a solution called MyFirstSolution and inside I have project with name MyFirstProject. Inside that project I'm installing nuget packages like Dapper, EntityFramework etc...
How things should work:
packages folder should be created into the folder MyFirstSolution and inside should be downloaded and installer all nuget packages referenced into the project.
The problem I'm having is that the packages folder is not created and the nuget packages are downloaded one level above the MyFirstSolution folder into some folder called XYZHelper.
When I download a solution from some repository nuget packages are restored to that same folder, not to the solution itself and references in csproj file says that they should be in solutionFolder\packages so all of my projects don't build.
If I copy the packages manually to the folder that they should be, it's all good but after every build a copy is made into that XYZHelper folder.
I don't have any postbuild events or anything like it configured into the projects. It is something with the visual studio I guess, but I can't figure out what.
How things should work: packages folder should be created into the
folder MyFirstSolution and inside should be downloaded and installer
all nuget packages referenced into the project.
Hi Stdfan, not sure about your VS version. But for VS2015 and earlier versions, the nuget packages are controlled by packages.config file. And things should work like what you mentioned.
But for VS2017 and VS2019, they have two methods to manage nuget: Packages.config and PackageReference. And for PackageReference format, the packages are stored in C:\Users\xxx\.nuget\packages. So if your vs version is VS2017 or VS2019, you can try if changing the format to PackageReference help resolve this issue.
The problem I'm having is that the packages folder is not created and
the nuget packages are downloaded one level above the MyFirstSolution
folder into some folder called XYZHelper.
Direction1:
Like zivkan suggested,I also think something affects the restore process.Normal for Packages.config format, the folders would be stored in packages folder. But according to
this document, we can customize nuget.config file to control nuget behavior. So please check locations where nuget.config exists,there might be some changes in the nuget.config for computer or some settings in nuget.config for users which causes this issue.(The nuget.config for user won't exist unless we create it there)
Direction2:
When I download a solution from some repository nuget packages are
restored to that same folder
As the restore process is invisible in build output, so there is possibility that the nuget restore works well, but something in build process move the content of packages folder into XYZhelper.
Check customize your build. Please check your directory structure for the Directory.build.xx file, it can affect your build process if it exists in any folder of the structure: C:\xxx\lancel\source\repos\
I don't have any postbuild events or anything like it configured into
the projects. It is something with the visual studio I guess, but I
can't figure out what.
This is not about VS normal settings. I think some custom file causes this issue(no matter nuget.config or directory.build.xxx), and please check if you've installed any third-party software or vs extension. Try close vs, delete the .vs, bin and obj folders and then run vs as safe mode.
Target folder of nuget packages can also be set using the envirenment variable NUGET_PACKAGES.
And you can do this in your existing project-file like this:
<Project Sdk="Microsoft.NET.Sdk">
...
<Target Name="NugetPublicfolder" BeforeTargets="PreBuildEvent">
<Exec Command="SET NUGET_PACKAGES=C:\MyProjectA\libraries\"/>
</Target>
...
</Project>
Now when you build/publish the project the libraries will be placed in C:\MyProjectA\libraries\
Actually the nuget packages are first downloaded to the socalled http-cache folder (%userprofile%\AppData\Local\NuGet\v3-cache), where it will be extacted from to the above folder (which is called the globalPackagesFolder folder)
The solution packages folder can be changed with a nuget.config (the setting name is called repositoryPath). So, check for nuget.config files that might be setting this value. You can get an exact list of nuget.config files used by a restore by downloading nuget.exe from nuget.org/downloads and running nuget restore MyFirstSolution.sln. Near the end of the output it will list every nuget.config file that was read.
When there is no config file that changes the solution packages folder (repository path), it always defaults to a subdirectory named packages in the same directory as the .sln file. The only way I know of to change this location for packages.config projects is with a nuget.config file, so I feel confident you should be able to solve it by finding the right config file.
Those files are created during package restore that's why I assume they don't have to be in the repository. Is there further documentation of the purpose of those files which might help to answer the question?
For a .NET Core project the nuget.g.targets and nuget.g.props are generated by a NuGet restore. They are created in the obj folder. So you do not need to have these in version control. Typically files in the obj folder are not included in version control.
Visual Studio will automatically restore these files on opening a solution if they are missing.
If you are using a build server then you can run dotnet restore to restore these files. MSBuild 15 when installed with Visual Studio 2017 can also be used to restore these files by running msbuild /t:Restore for the solution.
The nuget.g.targets and nuget.g.props files define various properties, such as the path to where the packages cache is on your machine. They also include any MSBuild imports that NuGet packages referenced by your project need.
For example, if you have the Microsoft.Net.Test.Sdk NuGet package referenced, the nuget.g.targets and nuget.g.props import MSBuild files that are included in that NuGet package. When using a packages.config file these imports would be added directly into your project file (.csproj).
.targets files are included referenced from the project file, thus need to be in place when the project file is read. If NuGet package restore is done at the start of the building the project then those files do not exist at the point the project file is read.
Hence putting these files into source control so they always exist when project files are loaded.
A different approach is to have a project (which all other projects depend on) that forces NuGet Package Restore for the whole solution (but doesn't itself use any packages). After it has build then all targets files are in place when the project files are in place.
Of course many NuGet packages do not use such files and this is not an issue.
I updated to VS2015 this week and along with that updated all NuGet packages in my website solution.
The site builds and run fine locally, however when doing my gated check in to my build server, I get the following when the build fails
As you can see the packages are complaining about the NuGet version, but I'm unsure how to update the NuGet version on the build server. I do have admin privileges to the server, but following the guild described at: http://blog.stangroome.com/2014/02/04/update-nuget-exe-version-used-by-team-build-2013-package-restore/ did not help. For one, my folder was actually C:\Program Files\Microsoft Team Foundation Server 11.0\Tools unlike the C:\Program Files\Microsoft Team Foundation Server 12.0\Tools described in the guide, but additionally I did not have a NuGet.exe within the folder.
I've done a full hard drive search of NuGet.exe, but could not locate it in any directories aside from the directories that are directly related to project source code (.nuget\NuGet.exe).
I have opened visual studio on the server and updated the NuGet version within "Extension and Updates" hoping that would fix the issue, unfortunately it did not.
Any ideas on how to fix the issue/errors presented in the screenshot?
The problem is that you're using the old-style, deprecated-since-NuGet 2.7-style "package restore" that's based on modifying your CSProj files to include references to a NuGet.targets file and a copy of NuGet.exe that gets put into a .nuget folder and ends up source controlled.
Basically, the version of nuget.exe that's on the build server is irrelevant right now -- your CSProj files are pointing to the file in your .nuget folder.
TFS 2013 and beyond has support for automatic package restore without using the NuGet.targets method. You can migrate off of it pretty easily: https://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore
I have a dependency on specific nuget package. When I update my solution to use new package version and commit/push solution to remote GIT repository, other contributors to solution, after pull, are still using old DLL version of nuget package, even though package-restore is activated. However, when they open CSPROJ file, it shows that reference should be to the new version. Basically Visual Studio is not generating any warning/error if there is a mismatch between used DLL from bin/obj folder and referenced DLL in csproj file. To be more concise:
Solution uses DLL version 0.5
I upgrade via Nuget to DLL version 0.6
My Visual Studio shows that version 0.6 is used
I commit/push solution to GIT
Another colleague pulls solution from GIT
His Visual Studio shows DLL version 0.5, there is no error/warning
His CSPROJ file references DLL version 0.6
Solution fails on runtime as there is change in internal implementation
How do we fix this:
Colleague deletes his bin/obj
Visual Studio notices that DLL's are missing
He uses Manage Nuget Packages on solution level and just clicks OK, nothing else
Nuget downloads DLL's and issue is solved
Now this is really stupid workaround and in my opinion this should be automated. Is there anything that we might be doing wrong that is causing this to happen?
GIT for VS doesn't take into consideration nugget packages (neither build generated files in \obj and \bin folders).
For Git to manage packages for versioning edit .gitignore file by commenting (#) line below :
# Enable "build/" folder in the NuGet Packages folder since NuGet packages use it for MSBuild targets
#!packages/*/build/
(nb : if you want to backup and rename .gitignore file, go there)
I have a visual studio 2008 database project that is under version control (git). I am getting conflicts in the project_name.dat when I try to merge my branches.
So my questions ares:
What is the project_name.dat file?
Do I need it? That is can I leave it out of my version control
No , you shouldn't have it under sourcecontrol as it's autogenerated.
Offtopic but maybe useful:
You should configure your VCS so that special files and folders will be ignored during your commit.
I use Subversion in a Windows environment and the only thing to do is to put a file called config in %APPDATA%/subversion.
Inside it look like this:
global-ignores = \bin \obj .suo _ReSharper *.resharper *.user *.ncb \Debug \Release