How do I clone a Visual Studio 2019 Solution? I don't need to rename it. The clone simply needs to go into a different folder, or could even go onto a different disk.
This question has been asked and answered many times, but the solutions don't seem to work for my use case. The simplest solution seems to be to Copy and Paste the Solution folder. But when I try to open the clone with Visual Studio, I get an error code 0x800004005. I have verified that 100% of the files in all the folders and subfolders of the clone are binary identical to the original prior to opening the clone. The original solution still opens fine after making the clone. If I dismiss the error code window, the clone looks fine and seems to behave fine. If I close, Visual Studio and reopen the clone, it seems to open fine the second time without generating the error code. I'm wondering if the clone is safe to use at that point.
A worrisome aspect of this simple cloning process is that there are numerous instances of files in the solution that store the names of other files in the solution, and the names are stored with absolute file paths all the way back to the drive letter C:\ So the simple copy and paste clone has lots of pointers to files that are in the original solution. This seems very wrong. After getting and dismissing the 0x800004005 error code, many but not all of the file paths within files in the clone now point to files in the clone. But some file paths in the clone still point to the original. I would be happier if they all pointed to the clone, and if the error code 0x800004005 never occurred.
Doing a Copy and Paste of the existing Solution folder seems to be complete and correct answer for making a clone of the existing solution when a project does not need to be renamed. This is an answer which has been given before, but I ran into some problems and concerns with using the answer. Some comments are therefore in order.
All the absolute file paths I found in files in the solution were in the .suo file, in .log files, and in .tlog files. These are all temporary files that can safely be deleted. They will be rebuilt or rewritten as needed, and they do not affect the Build>Build Solution process. Also, a Build>Clean Solution will delete the .log and .tlog files in any case.
The file paths used during a Build>Build Solution are all relative file paths and are stored in the .vcxproj files. That is why simply doing a Copy and Paste of the Solution folder will "just work" to make a clone.
I can't explain why I encountered the error code 0x800004005 when I opened the cloned solution with Visual Studio. But it seems to be the case that the error code can be safely dismissed and ignored. It is definitely the case that it can avoided by doing a Build>Clean Solution in the existing solution prior to doing the Copy and Paste of the existing Solution folder to make a clone. I therefore recommend doing a Build>Clean Solution in the existing solution prior to making the clone. I also recommend deleting the .suo file in the existing solution prior to making the clone. That way, none of the traces of the existing Solution folder are propagated anywhere into the clone.
Related
Coming from a Unix background and used to working with the Makefileto build stuff, I now have to find my way through the maze of twisty little passages known as Visual Studio 2017.
Basically: I just want to save a solution that I've imported into Visual Studio 2017 (e.g. to move it to another machine) to some sensible structure. I am unable to figure out how to do that!
The solution I work with comes from GitHub and the package is about 590 Kbyte and consists of 32 files. (I downloaded the .zip and unpacked it, then opened in the IDE by clicking on the .sln-file.
After running it (unchanged) in Visual Studio, it has ballooned to 4 Mbyte and 134 files. Obviously a lot of temporary files has been created as a result of me running it. Making a copy of this bloated directory structure is not practical - and some other way (i.e. the method for saving used by the guy who shared his solution on GitHub) must exist.
I want to save it with all those temporary files removed.
There is Build » Clean Solution – but it does not seem to get get rid of the temporary files.
I've also tried: File » Save all. I do no understand how this commend is supposed to work. It does not ask where to save tings, but just says "Item(s) saved" at the status bar at the bottom of the screen. Looking at things in the file system, I am unable to located anything saved. To me, it looks like this command does nothing.
I've searched, but so far found nothing for Visual Studio 2017 (recipes for older versions does not seem to work anymore.)
Saving a solution is something developers do a lot, so there must be something obvious I've missed.
There is not really the concept of "Save As..." for a solution. If you want to copy the whole solution elsewhere you would usually just copy the whole folder it's in to somewhere else.
The reasons you have many extra files are:
There will be a .git sub-folder which contains the Git repository. If you don't need to retain any link to this, you can delete / avoid copying this. Depending on how much history is in the Git repo this folder can even be much larger than the solution itself.
VS will create a .vs sub-folder for various housekeeping activities; you can usually avoid copying this.
In each project's folder, after you've built the solution, there will be obj and bin sub-folders. These are recreated as needed at build time and are not needed for a copy.
If you copy everything ignoring the above, you will probably find the size of the target is more as you were expecting.
I need share to share certain files between different projects. Thus I have a file structure like so:
D:\shared\
D:\shared\files-shared-by-all-projects-here
D:\project1\
D:\project1\project1-specific-files-here
D:\project1\shared <- directory junction to D:\shared
D:\project2\
D:\project2\project2-specific-files-here
D:\project2\shared <- directory junction to D:\shared
I have setup GIT repos in D:\project1 and D:\project2 My problem is that GIT seems to only track files in non-junctioned (i.e. real directories).
I use Visual Studio 2015 for both projects, and it's Team Explorer would behave very strangely when project has files from "junctioned" directories:
Upon adding a file residing in a directory junction to a project, Team Explorer would only show its parent directory (junction) in the list of changes to commit, not the file itself.
Upon committing all changes (i.e. files have been added), Solution Explorer shows all files as being tracked and checked-in (including those that reside in junctions and were not shown in the list of pending changes after they have been added:
Editing a file which is shown as checked-in and resides in a junction directory will make it appear to be checked-out:
Returning to Team Explorer now, the checked-out file is shown in the list of modified files:
However trying to commit it fails with a message: "An error occurred. Detailed message: No changes; nothing to commit."
Returning to Solution Explorer the changed file for which commit failed is nonetheless shown as checked-in:
Explicitly adding files that reside in the shared directory (i.e. referencing it via D:\project2\shared\some-shared-file) from outside of Visual Studio using Tortoise GIT for example does not work: add fails with a message that it is both a file and a directory.
The above was done with a new test project where frame directory residing in project's root is really a junction.
In my actual projects however the situation is slightly different... If I browse the repo using Tortoise GIT for example it would actually show the shared files residing in junctions as being tracked and checked-in and part of the repo. However as soon as I open the project in Visual Studio, it would show though same files in Solution Explorer and Team Explorer Changes as "pending delete". So is this a VS quirck?
So the bottom line is I just want to know how can I make files residing in directory junctions to be viewed as part of the project on par with regular files, so that they are properly checked out and checked back in and form part of project's (repo's) history?
At present, this is not supported. This is due to a difference in interpretation between junction handling between Git for Windows and libgit2, which is the Git library that is used by Visual Studio and (parts of) TortoiseGit.
It has been decided that both implementations should treat junction points as if they are Unix mount points, however neither implementation actually does that at present.
At present, Git for Windows treats them as if they were normal directories (and so it may delete your junction and replace it with a new directory). libgit2 treats this like a symbolic link, and as a result, Visual Studio refuses to deal with it at all.
Since Microsoft will need to update Visual Studio to fix this, please file a bug at Microsoft Connect and encourage people to vote for it in the hopes that it will get fixed in VS 2015.
I'm working on a project where I'm writing a library. I have a file, lets call it... tester.cs which I use for testing the library. Now, I'm only supposed to check in the library but i accidentally also checked in tester.cs. Is there any way I can delete it from the remote server without deleting it locally? and also ultimately removing it from source control? Thank you in advance.
If you want to delete files on the TFS server and leave them locally. There's the obvious brute-force solution of copying the files to a temporary location, fixing source control, then adding them back in to your project.
And also here is a similar question for your reference: How to delete a file from TFS repository without deleting local file
It depends really on what you mean by 'delete'. TFVC has the concept of delete which flags a file as deleted in the Project Collection database (and removes it from your workspace etc.). And you have the concept op 'destroy' which means the file will be removed from the Project Collection databases, and action that is unrecoverable except by restoring a backup of TFS. But this will leave your local file in place and erase all traces of the file in source control.
However, if you added it to your project in VS (.proj file) then there will be a reference to the file in there as well for compilation etc. This will cause issues when other users perform a Get-Latest of your solution.
Also if you are using a local workspace you can use .tfignore files to prevent such files from being added into the local workspace in the first place. See this page, near the bottom there is some information about the .tfignore file and how they work.
I think it's as simple as making a local copy of a file, deleting it in TFS and moving the local copy back to the original location. Visual Studio does not allow you to do that in a C# project or Source Control Explorer.
I am trying to use subversion and am having a tough time. The documentation is unclear at times. Basically I am trying to figure out how to merge but that causes conflicts because of files that should never have been included in the repository.
I issued a svn import command. That put the *.suo and bin and obj folders in the repository. I then added the svn:ignore command to the top level folder of each dll to ignore *.suo, *.user bin and obj. But this still causes problems because compiling the project (50+ dlls) creates these folders and since they existed in the repository before this causes conflicts.
So I presume that I need to create the repository without these files. But I can't use the svn:ignore command without a working directory as far as I know. Maybe the tortoise gui can do it but I am trying to learn the tool itself. If it can not do this I would like to know.
Thanks
JM
First rule of merging: always have a pristine checkout as the merge target. That means, only versioned files in the checkout, no modified, added, deleted, unversioned or ignored files and folders. I ensure this by using TortoiseSVN's Cleanup command, ticking everything:
From what I understand about your question, it seems you've SVN-Added-and-Committed some files and folders that should have been svn:ignored in the first place. So, using TortoiseSVN, select the files, and choose TortoiseSVN -> Unversion and add to ignore list -> *.ext:
Do the same for the folders, but Delete and ignore by name instead.
What this does is an svn deletefollowed by adding an svn:ignore property on the containing folder with the file/folder pattern set.
And then, commit the changes.
After that, do the SVN Cleanup as detailed above to delete the now-ignored files and folders, and then conduct your merge.
It's worth noting that VisualSVN automatically adds the svn:ignore patterns for projects newly added to a solution.
Hope this helps.
I found the answer was to use the global-ignores in the config file which can be found in:
C:\Users\%User%\AppData\Roaming\Subversion\config
I tried using the svn:ignore and that appears to work in the short term. Try to do a merge and it causes conflicts. The config file should look like this:
[miscellany]
global-ignores = *.suo *.user bin obj
But the global-ignores is really a local global-ignores. It is local to your machine but global to all your commands / repositories. Anyone else doing any imports will need their file updated or any projects they import will suffer the conflicts.
Are you using Visual Studio? Then, use AnkhSVN. This will do several things:
It will automatically not commit special user specific VisualStudio files that are causing you so much heartache into your repository.
It allows you to use Subversion from inside of VisualStudio. No need for a separate client.
It will make sure to use _svn folders to store Subversion working directory information rather than `.svn.
Also, consider a pre-commit hook that will prevent users from committing these types of files. I have one that I've used for years. It can be used to prevent users from committing any files that end in *.suo, .user, or directories called bin and obj. This makes sure that other developers in your group don't do nasty stuff.
I have a solution that links to several library projects located elsewhere on my hard drive (outside my solution folder).
I would like to change things so that these project folders are now inside my solution folder.
So far, I have copied the project folders into my solution folder. Taking a look at the .sln file for my project, I noticed that there are a bunch of entries that looks like this:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "FooBar", "..\..\..\Libraries\FooBar\FooBar.csproj", "{89FABBC5-4019-4887-AFE3-B005B0471486}"
I was thinking, Wouldn't it be nice and easy if I could just get rid of ..\..\..\Libraries\ from all the relative paths?
However, these GUIDs are scaring me off. If I leave the GUIDs the same, will this cause problems?
Oh, and if you know a better way to do this, please let me know :)
Yeah sure - the GUID's are unique identifiers for the individual projects, but they are not linked to the project's path in any way, shape or form. Just an identifier that is used later on in the .sln file.
To be absolutely on the safe side :-), make a backup copy of your *.sln, then edit, and open the newly edited .sln in your Visual Studio.
For the most part, this seems to work, but I ran into problems with my Setup Project/Installer. When I re-opened my solution after editing the .sln file, my solution wouldn't build. I got the following error:
An error occurred while validating. HRESULT='80004005'
I tried completely deleting and rebuilding my Setup Project from scratch, but the error remained. The only thing that worked was to remove and re-add each project using the Solution Explorer in Visual Studio.
So the lesson is: Edit the .sln project file at your own risk. If you have a Setup Project, it very well might break.
Update
Here's a link further explaining the "HRRESULT" error:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434666