I have a standalone project that contains some code I'd like to re-used. I created a library project in order to contain that code. There does not appear to be a way to move files from the one project to the other. (cut/paste in solution explorer did not work)
I then manually copied the files in Windows explorer (outside of VS) into the library's main "folder" but they didn't show up in solution explorer either.
Anyone know of a way to do this without having to manually create each file in the library and then copying/pasting the code into the files?
You need to copy the files and paste them into your solution/project folder(s). Once the files physically exist within your solution/project folder structure (Windows FileSystem / Explorer), then you right-click on your project within Visual Studio, select Add then Existing Item. Browse to the location of that file and open it. It will now exist within your project as a code file.
If you have two projects within the same solution, you can simply drag the file from one project to the other within Visual Studio Solution Explorer. That will create a copy of the class in the new project. You can then remove the old one and clean up any code references in the first project.
I searched already on stackoverflow and on the internet but I couldn't find a similar specific question.
When i have to rename a already checked-in (tfs) project in my visual studio (2010-2013) solution, I always use a procedure similar to this one here in the accepted question:
stackoverflow.com/questions/2043618/proper-way-to-rename-solution-and-directories-in-visual-studio
Here is the important snippet from there (thanks to author):
Close Visual Studio.
Create a backup of your .sln file (you can always roll back).
Imagine you want to rename directory "Project1" to "Project2".
If not using source control, rename the folder from "Project1" to "Project2" using Windows Explorer.
If using source control, rename the folder from "Project1" to "Project2" using the functions supplied by source control. This
preserves the history of the file. For example, with TortoiseSVN,
right click on the file, select TortoiseSVN .. Rename.
In the .sln file, edit all instances of "Project1" to be "Project2".
Restart Visual Studio, and everything will work as before, but with the project in a different directory.
..and there i always do step 6:
Step 6.: In the .sln file, edit all instances of "Project1" to be "Project2".
By observing the .sln file i could see that until step 6 (so in my case of using the tfs i did steps 1,2,3 and 5) there are still occurrences of the old project name in the .sln file:
Project("{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}") = "Project2",
"Project1\Project2.csproj", "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"
and:
SccProjectUniqueName92 = Project1\Project2.csproj
SccProjectName92 = Project1
SccLocalPath92 = Project1
Until now i had no problems with that approach. But as i could see a colleague of me is skipping step 6 and there are still occurrences of the old project name in the .sln file.
Now i wonder if step 6 is really needed/required?
I am keeping using step 6 just for more cleanness! But whats your opinion on this?
Could the old project name occurrences in the .sln file (if skipping step 6) even some time lead to functional problems with tfs/vs etc.?
Or is it only for the purpose of a cleaner/clearer code better to do carry out step 6?
If you are renaming a project within a solution, that is under source control, really all you need to do is to rename the project in Visual Studio and then submit the changes to the project file and the solution file, back into source control.
Visual Studio and TFS should handle all of the changes for you, VS will rename the project and update the references in the SLN file.
TFS will handle the rename and will maintain the history line.
The only time it should get complicated is if you are moving projects and solutions within source control, when you are carrying out this sort of task then the list above is a fair description of what needs to be done, but after step 4 i would just open the solution remove the project that can no longer be found and add in the newly renamed project, this would then automatically handle the sln file changes. now obviously this would orphan your history on the project if it was under source control, but you would make the project name change through TFS before reopening the solution.
if you want to manually change the sln file then a find and replace operation is the simplest way to update the file.
Coming Back to your question.
You really should ensure the sln file is correct as this tells VS where to download the files from and what projects actually make up the solution, by not updating the sln file correctly you, or other users of TFS may not get the correct files downloaded and you may have issues opening your solution.
An example of fall out from not having these files in line can be found in this question Why missing <SccProjectName> in project file cause "The project file is not bound to source control"
I've search everywhere for this, but have yet to find the answer.
I have a VS2012 project with thousands of files and folders I wish to exclude from the project as I don't need them to build any longer. Clicking on the folder and choosing Exclude From Project works, but takes literally forever - at times it appears Visual Studio has stopped running and I have to kill the process.
Question: What is Visual Studio actually doing to exclude a file from a project? Is there a way to simply go into the project file and exclude the files by folder? My project file does not appear to store this information. Where are excluded files defined for the project?
You can open the project file (in s text editor, i.e. Notepad) and remove the lines with the files that you want to exclude.
You can also do that in visual studio but you first need to unload the project (right-click on the project, unload)
Delete the folder in VS which has project to unload then restore it from recycle bin.
It works for me.
How do I move a project to a different folder in Visual Studio? I am used to this structure in my projects.
-- app
---- Project.Something
---- Project.SomethingElse
I want to rename the whole namespace SomethingElse to SomethingNew, what's the best way to do that (without manually going into .sln file)?
Remove the project from your solution by right-clicking it in the Solution Explorer window and choosing Remove. Move the entire project folder, including subdirectories wherever you want it to go. Add the project back to your solution.
Namespace names is something completely different, just edit the source code.
I tried the suggestion to remove and re-add the project, but then fixing up dependencies can be a pain.
I use this approach:
Move the project folder.
If the project is in source control, do the move using source control commands.
Edit the solution file in a text editor. There should be only one path that you need to change.
Close your solution in VS2012
Move your project to the new location
Open your solution
Select the project that failed to load
In the Properties tool window, there an editable “File path” entry that allows you to select the new project location
Set the new path
Right click on the project and click reload
Summary: rename-and-move in VS2019 with git, retaining git history, leveraging R# a bit, automatic dependent project reference updating (important for sln's with many projects, we have >200)
I have been using the following steps to rename-and-move C# projects in Visual Studio 2019. This process uses R# to adjust namespaces. The git history is retained by doing a "git mv" (avoiding add/delete history drop).
Two phases: 1) rename the project in place and 2) move the project.
(Uses tip from base2 re unloading projects.)
Rename
VS | Solution Explorer | right-click project | Rename (e.g., Utils.Foo to Foo).
VS | Solution Explorer | right-click project | Properties | change assembly name, default namespace and Assembly Information fields
Do 1 and 2 for corresponding test project (e.g., Utils.Foo.Tests)
VS | Solution Explorer | right-click projects (production and test) | Refactor | Adjust Namespaces
XAML files that use the project may need to be updated (manually or with an appropriate global search and replace)
Rebuild All
Commit!! (to commit changes before moves)
Note: The folder in Windows Explorer remains the old name to this point (e.g., Utils.Foo). This is fixed in the move steps.
Move
This method: 1) retains git history, 2) leverages R# to adjust namespaces atomically and 3) updates dependent projects en masse (avoids tedious manual editing of dependent sln and csproj files).
unload all the projects in the solution (so that removal of the target project does not trigger changes in dependent projects)
VS | select all solution folders under the Solution | right-click Unload Projects
move folders using git (so history is maintained)
a) open Developer Command Prompt for 2019
b) git status (to illustrate “nothing to commit, working tree clean”)
c) git mv the project
e.g., git mv "C:\Code\foo\foo\Utils.Foo" "C:\Code\Foo"
d) git status to view/verify change
remove the project
VS | Solution Explorer | select project | right-click | Remove
(since all projects are unloaded, this will correctly NOT remove the references to it in dependent projects)
re-add the project (to the new location in the tree in Solution Explorer)
a) VS | Solution Explorer | select target parent folder | right-click | Add | Existing Project
reload all projects
IMPORTANT: Confirm that *.csproj files for dependent projects have been updated.
(VS | Team Explorer | Changes | double-click any dependent csproj listed | inspect-verify ProjectReference path change)
Manually fix paths in the single moved *.csproj file
Use Notepad++ (or other text editor) to fix the paths. Often this can be done with a simple search-and-replace (e.g., ../../../../ to ../../).
This will update...
a) GlobalAssmeblyInfo.cs references
b) paths to packages
c) paths to Dependency Validation diagram files
d) paths to ruleset paths (e.g., <CodeAnalysisRuleSet>..\..\..\..\SolutionDependencyValidation\IgnoreWarnings.ruleset</CodeAnalysisRuleSet>)
Close and re-Open the solution (to get the project references into good shape)
Save All, Close Solution, I prefer to delete bin and obj folders to be clean of history, Re-open Solution
Validate
a) VS | Team Explorer | Changes
i) should see Staged Changes that reveal the files that moved
ii) should see dependent projects (*.csproj) that were nicely updated
review the csproj diffs and notice that the paths have been beautifully updated!! (this is the magic that avoids laboriously manually updating the csproj files using a text editor)
b) in Windows Explorer, verify old location is empty
c) Clean Solution, Rebuild Solution, Run unit tests, Launch apps in sln.
Commit!!
What worked for me was to:
Remove the project from the solution.
Edit the project file with a text editor.
Update all relative paths to the "packages". In my case I had to change ..\packages to ..\..\..\packages since I moved the project to a deeper folder.
Load the project back into the solution.
I had the same problem. I solved with move the references and in less than 15 minutes, without change the references.
For me the solution was simple:
Move your files where you need.
Delete the folder with name .vs. Must be as not visible folder.
Open the solution file (.sln) using a simple editor like note or
notepad++.
Change the reference where your file is, using the following
structure: if you put your project in the same folder remove the
previous folder or the reference "..\"; if you put in a above folder
add the reference "..\" or the name of the folder.
Save the file with the changes.
Open the project file (.csproj) and do the same, remove or add the
reference.
Save the changes.
Open the solution file.
Examples:
In solution file (.sln)
Original:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "PATH1.UI",
"ScannerPDF\PATH1.UI\PATH1.UI.csproj",
"{A26438AD-E428-4AE4-8AB8-A5D6933E2D7B}"
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") =
"PATH1.DataService",
"ScannerPDF\PATH1.DataService\PATH1.DataService.csproj",
"{ED5A561B-3674-4613-ADE5-B13661146E2E}"
New:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "PATH1.MX.UI", "PATH1.MX.UI\PATH1.UI.csproj",
"{A26438AD-E428-4AE4-8AB8-A5D6933E2D7B}"
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") =
"PATH1.DataService",
"PATH1.DataService\PATH1.DataService.csproj",
"{ED5A561B-3674-4613-ADE5-B13661146E2E}"
In project file:
Original:
New:
Original reference:
....\lib\RCWF\2018.1.220.40\TelerikCommon.dll
New reference:
..\lib\RCWF\2018.1.220.40\TelerikCommon.dll
Most easy way, which I found for myself
I tried multiple times till I found a working way.. For example you want to move your project from sln folder to mySource folder.
Remove your Project: In the SolutionExplorer of Visual Studio select your Project you want to change the directory, Press Delete -> Project gets removed. It still remains in your sln folder.
Copy it to your Path: In the windows explorer copy your whole project to your mySource folder. -> Now you are ready to include it.
Include back your Project: In the SolutionExplorer of Visual Studio add Existing Project and select your project from mySource folder. -> Project is now back in your Solution.
Adjust your Project References: Check every Reference in your Project. On your Project -> Dependencies -> Project -> you see your project references. If there is a yellow Warning sign on a project reference than is it wrong. Delete your project reference and add it new.
Rebuild your Project: and let it Run. Afterwards you can delete your project in the sln folder, which is not anymore in use.
That works. Have fun :)
in visual studio comunity 2019, i did what Victor David Francisco Enrique says, but needed only to delete the .vs invisbile folder
It's easy in VS2012; just use the change mapping feature:
Create the folder where you want the solution to be moved to.
Check-in all your project files (if you want to keep you changes), or rollback any checked out files.
Close the solution.
Open the Source Control Explorer.
Right-click the solution, and select "Advanced -> Remove Mapping..."
Change the "Local Folder" value to the one you created in step #1.
Select "Change".
Open the solution by double-clicking it in the source control explorer.
In VS 2015
Unload your project in the solution explorer
Create a new solution
Copy the projects to the new solution's folder
Right click the solution, add existing project.
If you use some framework such as MVC, you may need to add the reference in the reference manager.
I figured out this try this it worked for me.
In visual studio 2017 community edition it creates a project at this path
"C:\Users\mark\source\repos\mipmaps\mipmaps"
This will create a access to file is denied issue
Now, you can fix that this way.
close your visual studio process.
Then, find your project and copy the project folder
But, first make a Sub-folder Named Projects inside of your visual studio 2017 folder in documents.
Next, paste the project folder inside of your visual studio 2017 Project folder not the main visual studio 2017 folder it should go into the Sub-folder called Projects.
Next, restart Visual studio 2017
Then, choose Open project Solution
Then, find your project you pasted in your visual studio 2017 Projects folder
Then clean the Project and rebuild it , It, should build and compile just fine.
Hope, this Helped out anybody else.
Not to sure why Microsoft thought building your projects in a path where it needs write permissions is beyond me.
I wanted the changes in Git to be shown as moves/renames instead of delete & adds.
So I did a combo of the above and this post.
mkdir subdirectory
git mv -k ./* ./subdirectory
# check to make sure everything moved (see below)
git commit
And adjust the paths of the projects and of the assemblies from the nuget Pkg's in the sln file via a text editor.
Copy the project folder to new destination
Remove your project from solution (Right-click the project in "Solution Explorer" and choose "Remove")
Then add existing project to solution (Right-click the project in "Solution Explorer" and choose "Add" then "Existing project")
Change path to "packages" folder in "YourProjectName.csproj" file (Open in notepad and change paths for linked packages)
This worked for me vb2019. I copied my source project folder. I then pasted the project, and renamed the the folder to whatever. In order to break the ties back to the source project folder, I temporarily renamed the source folder. I opened my destination project. The paths to the forms and modules were re-discovered in the local folder. I went through all my forms and modules to make sure they were working. I ran the project. I closed the project. I renamed the source project folder back to is't original name. I can open both projects at the same time without errors.
Close the solution and move your project to new folder/location
Re-open your solution
Project should be loaded with '+' sigh referring as non checked in part. All the files
of the project will be shown as Renamed.
If not working after reopening right click on the project and click unload and then
reload.
It worked in VS2019
Group related projects together using solution folders
See http://msdn.microsoft.com/en-us/library/vstudio/c6c756s6(v=vs.100).aspx
No sure why all answers have overlooked at the most simple solution. Just run the "Command Prompt app" (in the windows bar search for CMD and it will appear automatically)
then just type the following command (change the path where relevant for your own case:)
robocopy /E C:\Users\Peter\source\repos D:\Peter\repos
What robocopy does is to "copies file data from one location to another." and the "secret source" is the / E that means "Copies subdirectories. This option automatically includes empty directories."
Enjoy!!! :-)
If a VS2008 project is created initially with a web app project, and class projects are added, and the structure is like this:
Parent Folder
Web App Project Folder - (solution Files in this folder)
Class Project 1
Class Project 2
...
do you see any problems with moving the .sln and .suo files to the parent directory?
Parent Folder - (solution Files in this folder)
Web App Project Folder
Class Project 1
Class Project 2
...
I adjusted the .sln project directories and the solution seems to be working fine, but I'm wondering if this action will break something I didn't anticipate.
Only the project files determine their build outputs - solutions only link projects together into a logical entity, so that they can be loaded at the same time in a Visual Studio instance. If the projects are still the same, nothing's broken.
And the .suo file can be safely deleted. It's a user-specific file that simply retains a particular user's options for a solution. It contains nothing that's important to projects, build settings etc.
You can open your .sln file with whatever editor you'd like, even notepad, and see that it contains only references to your project files in it, you can modify it so that the relative paths to your project files in it match your layout. VS wouldn't have anything against it.
All build settings are stored in project files, so you don't loose any configuration changes you've done in your projects.