I'm writing a tool to automate documentation and deployment of code for our website and I came across an anomaly while testing and it throws into doubt my understanding of changesets.
What I'm seeing is a changeset referencing files that aren't actually part of the solution (although at one point they were).
As best as I can determine this is the series of events (all but the last step happened before I joined the company and so this is all deduced from source control history) :
A folder is added to a project containing around a dozen txt files which serve as templates for e-mails and these are checked in to TFS
2 weeks later four of the txt files are removed from the project but not physically deleted
2 years later a developer had a task to update e-mail templates and changed all the txt files in the folder including the four that aren't "in" the project
Developer checks in his changes resulting in Changeset X
When I look at Changeset X and its list of changes it includes an "edit" to each of the txt files including the four removed files. I've checked the CSPROJ file and there is definitely no reference to the removed files in there at the point the changeset was made.
When my code iterates through all the changes in the changeset it tries to marry up the changed file to the project it belongs to in order to identify what file(s) need to be deployed as a result of the change - ie if its .html or .jpg then it just gets copied but if its source code then I need to deploy the associated binary that gets compiled from the file). So when it finds these files and tries to find a project that they belong to it fails.
Should the changeset reference these removed files or is it a bug in TFS? Or could it be something that happened when the code was migrated from TFS 2008 to TFS 2012 at some time in the 2 years before the two changesets? If its not a bug then in what circumstances would you expect TFS to track changes to files not in the project?
I've tried to replicate it by setting up a totally new project and adding it to source control and then adding, removing and editing an associated text file but I can't get it to behave in the same way.
TFS is right. Visual Studio Solutions are a nice interface for visually managing a subset of files in Version Control. It is common to have more than one solution and change files in multiple places, but still is a single logical change that I want to record as a single changeset.
Related
I am using Visual Studio 2017 to write some stuff in C. When I open a new project, I have some default filters and in "add" option for the project there's only filter and no folder/directory.
I want my project to have a folder structure, but can't add folders to the project in Visual Studio. Looking online I can only find solutions for adding an existing folder to a project and not adding a new one.
How can I add new folders to a Visual Studio C project?
How can I disable filters?
The way that I think of Visual Studio 2017 (earlier versions of the IDE as well) and its presentation of files in File View is as a kind of virtual file organizing system. File View allows you to logically organize files, presenting the actual file system in a more helpful manner.
The icons that look like folders in the File View are not really folders but are instead labels, called filters, which allow you to group your files however you like regardless of how they are physically stored in your persistent storage area such as a hard drive.
Filters are more flexible by not corresponding to the physical file folder hierarchy as they allow you to organize files that are all in a single folder into logical groups. Filters allow this to be done at a finer grain than is typically used by grouping files in folders. Filters also allow you to group files that are in multiple folders together into a single logical folder within File View.
However filters can be confusing because most of us are so accustomed to file folder hierarchies that the filter methodology can disconnect the logical file as represented in a Filter from the physical file location located in a folder.
My typical methods of adding files
Typically what I do is to create the physical folders through Windows or doing a clone of an existing Git or Subversion or VS Team Services source tree. With something new I may use the New Solution or New Project wizard to create my initial starting point and then organize and add files and folders physically through Windows and then go into the Visual Studio IDE to create the Filters and then Add existing files to the Filters. In some cases I will create sub-filters within a Filter in order to better organize the files within a physical Folder.
For new files I will just use the Add New Item menu option to add the item to the proper project. If you right click on a filter name, the new file will automatically be added to the filter. In some cases when I have added additional filters to the project to organize files, I will drag the newly created item to the proper filter and drop it there.
This drag and drop is not changing the physical location of the file but is changing its logical position by moving it from one filter to another. To move the file physically from one folder to another, I will usually do that with Windows. Just remember that if you do physically move a file with Windows you must also modify the file's entry in the Visual Studio 2017 filter to which it has been assigned, I usually do a Remove on the file followed by Add Existing Item and browse to its new location.
It appears you can not have the same file in multiple filters within the same project.
In some cases when I Add New item, I will change from the suggested folder displayed in the Add New Item dialog to a different folder using the Browse button. And if I need a different extension to the file then I will make that change as well, a common action when adding a new C source file to a project which requires changing the .cpp extension to .c.
You can also use the Browse button to navigate to a folder where you can then create a new folder if you like using the right click menu that displays when you do a right click in the displayed list of files and folders.
Unfortunately, the Add New Item dialog always wants to put a file into the project directory with all the other files. The Add Class wizard doesn't give you the opportunity to specify anything other than the default project folder. I have in some cases created C++ classes using the Visual Studio IDE, removed them from the project, moved the physical files to where I want them to be and then added them back to the project.
The filter approach seems to work well because the total solution is divided up into multiple projects and each project has its own physical folder. The multiple projects may correspond to particular DLLs or static libraries or other components that are used by the solution.
See also Can I configure Visual Studio to use real folders instead of filters in C++ projects?
Example screenshots of folder and filters
Here is a Windows folder view of a small project of the resources being used:
And this is how I have the filters set up. Normally the list of resource files can be quite long however I have created two sub-filters to logically separate out bitmap files from icon files though they both share the same physical resource folder.
Also the filter named PepIncludes corresponds with an actual physical folder named the same while the filters named "Header Files" and "Source Files" are groups of files that all reside in the same physical folder which is named the same as the project folder.
The following screen shot shows how filters can provide flexibility. I have a folder with include files, PepIncludes, and I have the same collection of files in two different projects within this Visual Studio 2017 solution. In a solution with 30 or 40 projects, this can make it a lot easier to manage files. For instance you can see that after modifying the file "ECR.h" the fact that it has been modified shows in both of the filter file listings (the small red check mark next to the name).
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
We are using TFS and the added .ruleset files now participates in the check-in process. However, does not make sense to check-in those files. Just ignore the file on the source control does not solve the problem because those files are added in the csproj structure as well. Is there a plan to keep those files in a folder outside the project structure? Why, when connected to the SonarQube server, the plugin just download those files at the analysis time?
Thanks
There is no way to keep .ruleset files outside the project structure, as the rule set is to meet specific project needs associated with code analysis. It sits in a project properties.
Good Morning,
I am working on legacy code. This legacy code consists of multiple projects (language C with NI LabWindows CVI) and was never manged in a source control System but only in on folders. Over time it got a little messy and copies of this folder were created and changes were made to all folders depending the project that was built.
The result is, that there are 5 folders each containing different codes bases for what once was the same code. Also many files were modified in all folders because they are used in several projects. Each project was only build from 1 of the 5 folder (so project A was only build in folder 1, project b in Folder 4 etc.). It is not only raw code, but also user interface files.
I hope that was clear so far.
My task is to merge all the code into one one codes base (as it started of originally). And I would like to get some suggestions.
Here is the plan:
1. create baseline version of one folder that is supposedly that one with the most changes.
2. create GIT repository to store the code and all changes
3. go through all folders and merge files into baseline version using file diff software. (Folder 1 is baseline, merge folder 2 to baseline, merge folder 3 to baseline etc.)
Do you have any comments on this plan? What is good? Bad? Are there tools I can use?
This seems like as good of a plan as any. You have a mess on your hands either way.
If there are many changes to the user interface panels, that could be a headache. The UIR files are binaries, which will make git merges and diffs useless.
Go into each project and under Options->Preferences select the box to save .UIR files as .TUI files and save the project. This will give you a text file output describing the user interface and allow you to use diff tools properly.
EDIT
When the User Interface is active, you can directly select Options->Save in Text Format to do this as a one-off.
Good Luck!
It might also be worthwhile to use the UI to Code converter under CVI's Tools menu to convert all your UIRs to code. This should make them more compatible with text-based source control (like the save in text format approach), but may also ease the process of merging UIs.
When I have an SQL Server Database project (.sqlproj) in Visual Studio solution, I notice that that particular project always gets built every time I build the solution even though there is no change in the project files.
This is inconsistent with normal C# project (.csproj) that only gets built when there is any file that changes.
I have tried cranking up the msbuild output verbosity, and it seems to always build that project without special reason.
Is there a reason why .sqlproj is always built? Is there a way to make it build only when file changes?
MSBuild has the opportunity to make Incremental Build. The main idea of that is the following:
MSBuild attempts to find a 1-to-1 mapping between the values of these attributes. If a 1-to-1 mapping exists, MSBuild compares the time stamp of every input item to the time stamp of its corresponding output item. Output files that have no 1-to-1 mapping are compared to all input files. An item is considered up-to-date if its output file is the same age or newer than its input file or files.
I don't know which targets are inside the *.sqlproj file, so you need to determine does it ever uses that technology, and if it do use - you need to examine which inputs and outputs involved, and try to clarify it by yourself, what is going on with them under the hood.