I'm currently working within a monolithic solution that is a conglomeration of several smaller projects and the result of many developers efforts. However, one of these efforts was not the creation of a standards document regarding naming practices for test classes. As such I have over 1500 individual test classes that may have a suffix of "Test", "Tester", or "Tests".
Is there a good way to batch rename all the *[Test|Tester].cs files within our solution to *Tests.cs taking into account the preexisting TFS and project file structure?
The solution that seemed to work for me was to do a Find & Replace via a regular expression across targeted test projects within my solution.
In the standared Visual Studio Find and Replace Dialog
I searched for public\W+class\W+([a-zA-Z0-9-_]+)Test(er)?\b
and replaced with the captured group of public class $1Tests
within all files matching *Test.cs;*Tester.cs
Importantly, and for reasons unknown to me, if I didn't check the "Keep modified files open after Replace All" the find and replace would fail
eg:
Once the find and replace operation was completed I used Resharper's Move Types Into Matching Files refactor function on the test packages in order to update references in both TFS and various project files.
Use a local workspace and your bulk renaming tool of choice. It doesn't have to be within Visual Studio. A local workspace will allow changes to the structure of the project to be made from any tool and still "noticed" by the pending changes window or tf.exe.
You'll still have to update the *.*proj files to take into account that the files have been renamed, of course.
Related
At my company, our software for one set of services is broken out into many different solutions containing any number of 350+ projects. My job at the company is to trace through all of this code to find where errors occur.
To facilitate this, I would like to have all of the projects contained within a single solution. I can do this via the 'Add Existing Project...' menu item, but it only allows me to add one project at a time. I also noticed that I can add existing items (multiple simultaneously) from Windows Explorer by dragging them onto a solution folder, but that doesn't import projects; it only adds the project file itself to the folder.
Is there a way to add multiple projects to a solution simultaneously? I realize that this may (read: will) take a long time.
I think you are looking for something like this:
http://nprove.codeplex.com/
This allows to load a a project or a folder with projects from the team foundation source control explorer into the current solution.
A solution would be to create a small program that takes as input the list of projects you want to add to your solution (or that scans a directory for *.csproj, *.vbproj...) and writes to the *.sln file of your solution.
If you open a *.sln file with notepad, you'll see there is no magic in it, it's just a text file that contains the list of projects (with their GUID) and some information about the build configuration.
Look at the structure of a solution file and try to write a piece of code that does the same as visual studio when user adds a project to the solution.
I'm pretty sure that can be automated with a small effort. Just a matter of file parsing.
Visual Studio Extension "Add Existing Projects" (Created by: Cyotek) allows you to add multiple projects to one solution by selecting all once. Worked perfectly for me on VS2017.
I could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
If I add a new file to a project under TFS source control, it will check out the project file and the corresponding .vspscc file for that project file.
The project file itself changes (to include the new file), but the .vspscc file doesn't change at all. Why bother checking it out? Is there a way to disable it from being checked out and if there is, should I?
It gets checked out because under certain conditions it will be modified..and thus they checked it out as a matter of default. I wouldn't worry about it..it's not hurting anything, and if you disable it, it might bite you badly in the future in a bizarre way.
According to this post of Ben Ryan:
Team Foundation uses these to store lists of files that have been excluded from source control. We leveraged some of the existing SCC integration layer in Visual Studio to integrate Team Foundation, and these files were one of the carryovers. I'll have to check into what the logic was in breaking out these SCC settings into separate files as opposed to putting them in the solution and project files' SCC sections.
This file is a holdover from past VSS/TFS implementations, like Paulo Santos posted.
On the solution level, I have found no functional use for these files. In 10 years of using TFS, I have never seen that file altered. You can delete these .VSSCC files, as I commonly do for my closed source solutions.
But if you delete the solution-level .vsscc file, you will get a non-destructive error message on the first time open of the solution file...only after a new branch is created. All subsequent solution opening will not show the error message again.
My TFS setup standards have the solution file alone in the root folder, all projects are under sub-folders. Since those .vsscc files double the number of files in my root, I always delete them.
On a project level, I leave those files, as my team never opens project files directly, only solution .SLN files.
For my team, I prefer programmer ease of opening solutions over that one-time error message.
I am working on a project using VS 2008, containing MANY files within projects
within solutions. We recently had to convert all our work from VS 2003 to 2008 (you know
how big companies are always the last to convert to the lastest version of stuff).
In trying a "Find in Files" (or "Quick Find") within 1 solution containing 3 projects, I am successful in my search within all 3 projects only when using "Current Doc" & "All Open Docs". But when using "Entire Solution" or "Current Project" only 2 of the 3 projects give me correct results. The Find will not show files within 1 project in particular that I KNOW include results from my Find.
After reading suggestions from:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=105511
I attempted every Workaround they had, and NONE worked for me. Any suggestions???
Setting find options
First try the following:
Ctrl+Shift+F (Find In Files)
Look in: Entire Solution
Expand Find Options
Whatever for Match case
Whatever for Match whole word
Uncheck "Use:"
Look at these file types: *.*
"Dealing" with some rare solution hierarchy issues
Next, if you have your projects organized into solution folders (as in you have this instead of this), try expanding each of the projects one time, as follows:
foreach solution folder in the project
expand the solution folder
foreach project in the solution folder
• expand the project node
• (optional) collapse the project node
(optional) collapse the solution folder
Additional details regarding expanding the projects: in my work on my Solution File List tool pane (in particular the Find in Solution Explorer feature shown), I found that sometimes files aren't found in the solution if the project hasn't been expanded once. Using the automation model, the problem always occurs, but using the lower level COM interfaces is more likely to work. The lower level interfaces are what Visual Studio uses internally, so most of the time people won't run into this problem. I use a lot of carefully ordered operations (aka hacks) to keep it working as much as possible, but every once in a while I still have to expand a folder before a file is found.
If all else fails
I'll need to know as much of the following as you can provide. These are relevant for all projects in the solution, not just the ones that aren't working for the Find in Files. For some Visual Studio operations, an exception will interrupt the remainder of the operation, so an exception while operating on project A might keep the find from reaching project B, etc.
What project types do you have in the solution? Especially if you are using 3rd party project types such as VS.Php (I think .phpproj) or nFringe (.ucproj). As a quick check, you can right click each of those projects and select Unload Project, then try the Find In Files afterwards.
What source control system are you using?
Do you have any 3rd-party add-ins installed? (Microsoft ones count if they are power toys, etc.)
Do you have any non-file-system files in the project? (Nodes in the project that don't map directly to a file on the hard drive.)
Does any project in the solution reference files on the network?
In an earlier question, I've found out that sadly Solution Folders are not real folders inside a directory.
I wonder if there is an AddOn or Macro that adds this functionality? i.e. when I create a Solution Folder, it created a real folder. When I Create a new Item (Right Click => Add => New Item) it automatically moves them into that folder, removing causes it to delete it from disk (after asking) etc.
This is for Visual Studio 2005, although we might upgrade to 2008 in a few months.
As of now, this doesn't seem to be possible in either VS 2005, 2008 and 2010 and there is no AddIn for this.
I too thought it was a strange idea. However it can be a useful tool to logically group projects in solutions without necessarily moving around folders in the file system.
I suspect you need this for revision control tool. In that case Look at AnkhSVN.
Maybe what you want is to add files to a solution folder as «links», i.e., keeping the files where they are but giving them a different organization inside the solution.
(when you add an existing file to a solution folder or to a normal project folder, if it is in a different corresponding physical folder, the file is copied).
It usually stays unnoticed, an option in the «Add > Existing Item ...» dialog where you can choose "Add As Link", instead of the "Add".
This allows to share files amongst projects, or, simply, organize them differently.
What I oftem miss is the possibility to add "virtual" folders inside a project, for organizational purposes, without breaking the namespace/folder best-practice.
Can't really get the point you want to add this function.
Sometimes you want to know if it can do this , however, the answer may be no. But it is not necessary means you can't achieve your original goal, there still a few ways to work around it without this.
Additionally, VS solution suppose to be the shortcut of your project settings and should not been included in any hard-code, the solutions may be various between the PCs and IDE envrionment.
I didn't really use VS2005 much, but have been using VS2008 for the past year.
It has a tick box for creating a solution folder when you create a new solution/project.
If you then use the "Solution Explorer" window you can create and manipulate folders and class files within them. This will actually create new directories that match.
Deletion of files from within the Solution Explorer will also delete the actual files from disk.