Possible implications of of adding *.sdf files to .gitignore - visual-studio-2010

I recently pushed a Visual Studio C++ project to github. I've noticed that VS creates a .sdf file that's relatively large (~25MB). I tried deleting this file in my workspace to see whether or VS would throw an error. Upon open the project in VS no errors where reported and it the file was recreated. I'm considering, therefore, removing the .sdf file that's currently in my repository and adding an *.sdf entry to the repo's .gitignore file.
The consequence of this is that when a user pulls the contents of the repo and opens it in Visual Studio for the first time, VS will have to generate the .sdf file. However, if a user pulls changes from the repo made by another user, could the .sdf get out of sync, and if so, does anyone know if VS would handle this in a sensible way (e.g. regenerating the .sdf file)? Could there be other implications that I'm not aware of?
Any input would be much appreciated!

It looks like *.sdf are usually included in .gitignore files,; as illustrated in ".gitignore for Visual Studio Projects and Solutions", but also on the GitHub gitignore project.
One potential effect can be regarding some local modifications being overriden: see "Local Data Cache Sync does not save client changes to sdf file".
But other than that, ignoring cache file from a source control repository is a good practice.

Related

Why is my .tfignore not ignoring *.vssscc?

I'm running VS Enterprise 2015. This infernal thing keeps wanting to add my solution's .vssscc file to version control. My .tfignore has this line:
*.vssscc
The other items in .tfignore are working fine, but for some reason this one is not. There are no other .tfignore files in the directory tree. Surely I'm overlooking something, but I'm pulling what's left of my hair out trying to figure out what. Any suggestions?
*.vssscc stands for Visual Studio Solution Source Control File
When a solution is added to source control, a corresponding .vssscc file is created. The text file contains connection information and an exclusion file list, similar to the project hint file. This file is temporary and exists only in the source control database.
As a rule of thumb, we'd recommend letting Visual Studio handle those files. It'll add to source control the files it needs and leave out those not needed.
.vssscc files also manage the solution bindings, so better to have them controlled (by VS) .
Also, visual studio can have problems with the source control bindings if the files it needs are not under source control.

Forget and Ignore a file in TFS while keeping it locally and in the project

I have a file that is currently:
Present in the TFS 2013 repository;
Included in the Visual Studio 2013 project;
And as such it's obviously also present on disk;
Previously, with Mercurial, I could just:
hg forget to remove it from version control;
add that file to my ignore pattern;
And all would be well. People that do a fresh/clean clone will see that file as "missing", which was exactly the point: everyone had (needed, even) his own local version of that file.
How do I emulate this with TFS? That is, how can I make sure:
The file is not present anymore in TFS 2013 repository;
The file is still included in the Visual Studio 2013 project;
The file might be present on disk if the user had created one;
Can I accomplish this with Visual Studio 2013? Do I need to dive into the command line?
If that file is already added to TFS Version Control, you need to run tf destroy command to delete it permanently from TFS server.
And, you need to create one .tfignore file to exclude one specific file during checking in. See: https://msdn.microsoft.com/en-us/library/ms245454.aspx#tfignore
and http://blog.appliedis.com/2014/11/06/excluding-files-from-team-foundation-version-control-using-tfignore-files/
In the end what I did was this:
Copy-paste "backup" of the file;
Delete the file from the solution explorer;
Put the "backup" back in the original file's location;
Edit the csproj (e.g. in Notepad) and revert the change done by TFS during step 2;
Check in these changes;
Warning: this does remove the file for others that currently have it. The file will show as "missing" for them after getting the latest updates from TFS. They will need to manually restore the file at that location (e.g. from an old version, or freshly created).
I don't think this is the proper way to do this, probably #Vickey's answer (i.e. use TFS command line and ignore files properly) is the correct way to do it. I just haven't gotten around to trying it yet. But this answer does work.

Prevent VS from checking out App.config from SourceSafe when I am making local changes to it

I am working with a project (shared by a small team via SourceSafe source control) with four .config files in it:
App.config is the configuration file that is eventually used when the program is executed.
The other three files are essentially templates that I can quickly copy & paste into App.config.
App.Integration.config and App.Release.config are valid for all team members. For instance, it refers to integration or production database servers on the network.
App.Debug.config is a template with settings that are valid only for my machine, e.g. because it refers to my local copy of a development database.
Background: Why am I managing multiple configuration files manually? ASP.NET web projects automatically support multiple configuration files, but other project types don't. I also know that this could be automated by adding a custom MSBuild task to the project file; however, this might break or confuse later build steps, such as ClickOnce deployment.
Obviously, I do not want to check in "my" local version of App.Debug.config into SourceSafe, which is why I told Source Safe to ignore that file. For the same reason, I have SourceSafe ignore App.config, because that file is often going to be edited, e.g. when switching from the local configuration file to the integration environment's version. If everyone checked in their versions of these files, they would be seen by all other developers.
However, if I understand correctly, this leads to SourceSafe no longer keeping a copy of these files at all, so if someone checks out a fresh copy of the project, these two files will be missing.
Is there a way to have an "initial" copy of e.g. App.config in my SourceSafe repository, but at the same time prevent Visual Studio from checking out the file when it is locally edited by a developer?
Background: Why am I using SourceSafe at all? It's not my decision, and I can do nothing about it in the short term.
You can use the pin feature to keep a copy but not allow checkout.
In solution explorer, locate your file (e.g. App.config), right click on it to call menu "Show History...", select a version of your file and then click button "Pin".

Should we ignore Solution Output folder while we are using Visual Studio and Version Control?

I'm using Bazaar and Visual Studio 2010 in a C# project. I have prepared an ignore list but still I think all the files in Solution Output directory could be ignored.
I search a lot but nobody had mentioned it. So I'm going to know if I can ignore this directory because output files are changing regularly and seems are not important for repository copy.
What do you suggest about this issue ?
In general, any file that is automatically generated by compiler or build tools should NOT be committed into source control. This includes object files, executables, generated resource files, symbols, etc. Committing those files does not serve any useful purpose. Also, sometimes there are configuration files which look like can be committed, but really should not if they only contain local user specific info - for Visual Studio there are *.user files.
By that logic, solution output folder should be always put into ignore list.

Visual Studio and TortoiseHg: folder not visible in VS

I created a C# project and added it to source control (mercurial). I can edit files in VS, commit it and push it using TortoiseHg. It goes to the server. When some one pulls they get the files.
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
However, now someone pulled the latest code from the server - and they got the new file (it is visible through windows explorer), but when they open the solution in VS, they don't see the file.
Does someone have an idea what is wrong here? or things I should check? Thank you for the help.
P.S. I have visual studio 2010 express (so I can't use the VisualHg plugin).
Visual Studio caches changes to the solution and project until an explicit save or a build. In your comment:
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
I see that an updated .sln or .vcproj file was not mentioned and checked in. Did you see an update to either of these files via TortoiseHg? If not, make sure to build or save your project after a change like this.
Did you make sure that the Visual Studio Project File or Solution file is being updated and committed?
VS solution contains projects and each project select managed files by metadata(***.vcproj file). It's not the way include all files from root directory.
So, your co-workers can see new added files by in following two ways.
1) share project file(***.vcproj)
2) manually add files in each person's VS instance.

Resources