Why does visual studio exclude BIN and OBJ folders

问题:

I want to know what is the generic way to check-in code on Azure DevOps from Visual Studio or Git-Bash that has been coded in Visual Studio. The problem that occurs is the bin folder contains many third party dll's which are kept in the source before building the project. Those third party dll's are necessary to project. However after check-in to Azure DevOps the bin and obj are not present. This happens due to .gitignore and .gitattribute files. I have deleted both the files and checked in the bin folder as of now. What is the purpose of these two files. Can someone please suggest a way to resolve.

回答1:

.gitignore file specifies the untracked files. .gitattributes defines attributes per path. They are configuration files of Git.

In Visual Studio, the bin and obj folders are used to store the output generated by compilers (see here). As these output files are generated by compilers, you don't want to track them in the source control.

If your project need to reference to some 3rd party dlls, the best approach is to reference to them as Nuget packages if there are Nuget packages available for the dlls. If not, you can put them in a folder other than bin or obj so they can be tracked in Git. You should not change .gitignore to track bin or obj folders.

回答2:

.gitignore is designed to exclude things from source control. For example if you had a file with your connection string to a database in your development folder you would not want your password checked into source control. Checking in binaries into your repository is a bad practice. You should be using dependency management system (like Nuget, Chocolately, Maven, npm, etc) to specify your dependencies and download them. The way you are doing it now you would check in multiple copies of them into multiple projects and not be able to management them in one place. Proper dependency management likely is the reason the default versions of .gitignore exclude certain folders. You also want to regenerate all the contents of the obj folder. If you have old copies timestamps get odd. A clean build every time means starting from a fresh copy without any compiled artifacts.

回答3:

To pile on: even if you do want to check in your bin folder (and, as others have mentioned, you do not), do not do this by removing the .gitignore and .gitattributes files.

.gitignore contains a list of files that should not be added to your repository. These are files that should not be shared with the team like local configuration data. If you commit the SQLite data in the .vs directory you will get countless conflicts and be unable to pull because Visual Studio will have that file locked.

.gitattributes contains a set of configurations, especially for line endings. This must exist in the repository for all developers to agree on the setup, or you will get conflicts around whitespace.

If you really must (and you mustn’t) check files in to your bin directory, restore your .gitignore and .gitattributes. Then explicitly list them in the .gitignore with a negation pattern:

!bin/foo.dll

But - as others have commented - this is still a bad idea.

回答4:

The bin folder is definetely the wrong place to store 3rd party dlls. Store them somewhere else and copy them to the bin folder during building or if available use NuGet packages. It is a widely used standard procedure to exclude the bin folders from checking into source control. Also if you decide to do a cleanup of your solution, your bin folders will get emptied out and your 3rd party dlls will be gone.

Another point, since your posting a question with the azure-devops tag, azure-devops provides a powerful building and testing pipeline. This means you can check in your code and the hosted build server (standard scenario, IF you set it up that way) will pull your code from source control and do a build, run some tests and if everything is OK zip your binaries and put them somewhere where you can dowload them. Now what happens to your own dlls in bin that you have checked in? They will get overwritten when the server builds your code. So why check them in in the first place? If the server does a cleanup (which it will not necessarrily do) then your 3rd party dlls will be missing.

回答5:

As most of them already provided great answers. I'd provide you with some ideas of how to handle the 3rd party DLL(Assemblies)

Please remember that ideal/best way of using 3rd part libraries is through NuGet Feed/Packages

For some case, those DLL's wouldn't be available in Nuget.org. In such case, you can follow this steps to add the references in your project.

1. Create a folder within your project called lib

2. Add the DLL in that folder

3. Right Click the DLL->Go to Properties, then Change the BuildAction to None and Copy to Output Directory to Do not copy for the DLL

4. Finally, Add the References from the lib folder

So when you are checking the projects into any version control the lib folder will also get check-in and during the build, the references will also get from the lib folder.

Remember again don't use bin/obj folder to refer your DLL's and Don't ever check-in bin and Obj folder. As those folders will be autogenerated during the build itself.