We have a large solution with many projects. Some of the projects were outsourced, and the vendor used TFS. When they commited into our SVN repo, some of the bindings are still hanging around.
When I open the sln, VS2008 says "The source control provider associated with the solution cannot be found, do you want to remove them". I hit yes, save and exit, and then next time it does it all again :)
So - anyone know how I cam get rid of any TFS bindings from the sln once and for all? Do I need to manually search the csproj files for any "scc" references and remove?
Thanks!
Some PDA deployment projects(.vddproj) had some bindings hanging around.
Just removed them manually :)
The way to remove the bindings is to search the csproj files and remove it. There is a similar question on this topic already: See: How to remove TFS source control bindings for a solution from the command line
Here's a PowerShell script to remove the source control binding info. It was ported from some C# and only tested on VS 2010 solutions. The original code was written for VS 2005 and 2008 so you could probably add the relevant stuff back in.
Here you can find a tool (including source code) to remove both SCC footprint from the solution and project files and the .vssscc and .vspscc files. In addition, it removes the output and other configurable directories.
Hth
Stefan
Related
I am working on two different solutions, say, Solution1 and Solution2. As these two solutions are dependent upon each other, I have to open two separate Visual Studio while developing.
It is really difficult to switch between these Visual Studio. I can't merge these two solutions into one as Solution1 is being used by other projects and all are part of Source Control.
Just wondering, can I open both solutions in the same Visual Studio IDE? I searched a lot but no luck. Any suggestions on existing VS AddIn or how to develop it would also be helpful.
Visual Studio version - 2012 Ultimate
Source Control - TFS
Create a third Solution C than includes project from both A and B: you can keep C as a local file i.e. you don't check it in version control if this can disturb the team.
Else you can open two instances of Visual Studio and switch at need: VS is smart enough to sense file system changes, but you have to be careful in saving before switching.
Does it have to be within the same IDE instance?
You could right click the VS icon in the task bar, select "Visual Studio 20__", and you will have two seperate instances of VS. You can then open separate solutions in both, without merging the two under one solution.
This will eat up far more resources, however. The previous responses are preferable.
What you are asking is impossible and extremely dysfunctional.
The supported solution would be to add all of the projects from Solution B to Solution A. Then you can open a single solution with all of your work. If you want compartmentalisation within your solution you can use solution folders.
If you can you should have a separate solution for the core components and package them as a nuget package. Both of your other solutions can then take a dependency on that single shared package.
open the solution 1 and right click and add the second solution. When you close the VS next time it will told you once to save the sln file. Do it for saving the settings in sln file.
Now everytime you will open sln1 will show you both project. It will not affect if you only move first project to pen drive or move to another computer. In case of 2nd project missing it will told you that 2nd project not found no more worries.
In case of Source Control - TFS I can't confirm how it work but their is some sollution for github (Which maybe hint anything for TFS).
The same trick can be applied but you don't need to push modified sln so this will not break anyone else's settings. If TFS store the files and code on the file system that you currently working then you can applied same trick to do applied this trick to that TFS project which is stored in your file system.
1.open solution1 in visual studio 2012 .
2.Right click on solution1 ,add existing project option.
3.select the solution2 .
4.Now solution1 and solution2 file are same project.
I have a dev team that is split in mentality of using visual studio source control bindings. Half would like the integration and half would not. Is there a way to add a solution only binding setup so each team could use a different solution based on their preferences?
There is no painless solution to this problem. The reason being that Microsoft made the monumentally bad decision to embed source control information into .NET solution and project files.
Let's say Dick wants to use the SCC plugin and Jane doesn't. Dick adds a project to version control via the plugin and information like this will be written to the solution file:
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 2
SccLocalPath0 = .
SccProjectUniqueName1 = someApp\\someApp.csproj
SccLocalPath1 = someApp
EndGlobalSection
and some garbage like this will be added to the project(s) files:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
In addition, some files will be strewn about the project folder tree (MSSCCPRJ.SCC files in the solution and project folders, a *.vssscc in the solution folder, and *.vspscc files in the project folders).
The extra files are not a problem as long as Dick doesn't check them into source control (although the plugin is always going to want to check in those .vssscc and .vspscc files). However, the source control information that gets written to the solution and project files will always be an annoyance for Jane. Whenever she opens the solution, she will be nagged by this message:
and then this one:
Should she choose the option to "Permanently remove source control association bindings", the source control information will be removed from the solution and project files and she will be happy again. However, Dick's SCC plugin won't work anymore and he'll probably rebind the projects to source control and an office riot will ensue.
To sum it up, you can share .NET project between those who use the SCC plugin and those who don't, but one or more parties are going to have to endure some annoyances because Microsoft decided to add source control information to .NET project files (such a bad decision, this wasn't a problem in Visual Studio 6).
I'm not absolutely sure if I got you right. I assume that half of your team wants to use the Visual Studio plugin to access Perforce and the other half doesn't.
This is possible. You have to make sure to never check in the MSSCCPRJ.SCC file created by the plugin. This is the local bindings information and will not work on everybody's workstation.
On the other hand side, the *.vssscc files can and should go into Perforce.
Using the plugin has one big advantage, though: The plugin knows which files to check in and which to omit. Especially when adding new projects, it's a common mistake to forget to check in the newly created files when using the Perforce visual client instead of the plugin.
You have to make sure to never check in the MSSCCPRJ.SCC file created
by the plugin.
I removed *.scc files but Visual Studio prevent me use others Source Controls Plugin's except saved into solution and project files.
I was working on a class in visual studio 2010 when suddenly my computer crashes. after I restart the computer. I start Visual studio and I find that class to be completely empty.
it contained more than 1000 lines of codes before the class.
is there anyway i can recover that file?
Help please because I don't have another copy of it (Stupid of me)
If you cannot find the source code file, try using Reflector to decompile the most recently built dll you have containing that class. It won't give you your complete source, but at least will give you something to start with.
Note: Reflector is no longer free; if that matters, try dotPeek from JetBrains instead.
Also, look into using a source code control system. This will let you 'commit' versions of your code to a repository, so you'll have a copy in case something like this happens in the future.
Subversion, Git, and Mercurial are popular ones; In my opinion, Subversion would be the easiest to start out with, especially with TortoiseSVN (OS integration) and AnkhSVN (Visual Studio integration). If you don't want to worry about setting up a repository/server, look into a hosted solution, like Beanstalk, which offers Subversion and Git and lets you try it out with a free, limited account.
Good luck - I hope you are able to recover your source!
Something which worked for me was back-up.
BTW I was trying to recover a VS2013 file on a Windows 8 machine.
Try to check in below location in your system.
C:\Users\username\My Documents\Visual Studio \Backup Files\ProjectFolder
I found an original file with original-date.filename.cs name and a recovered-date.filename.cs files.
The original was the one needed.
Deleted the one in project, added the original file and renamed it to file.cs. Tried building and debugging and it gave the expected results.
Also just want to add one more thing...
In my case i had an aspx page with its respective .cs and designer.cs
The .cs file got corrupted and I did build on project, with the designer.cs the project got build successfully and the dll got replaced. And when i tried to recover using reflector everything was in a state no return. :(
So don't build the project if you see any file got corrupted.
in visual studio 2019 I find the file in a files with TMP extension
FileName.cs~xxxxxxxx.TMP
This happened to me a few times as well when Visual Studio was crashed or System was shutdown unexpectedly.You can recover these corrupted file using Recuva. It dose not recover the file every time but in most of the cases it's work perfectly.
Below are the settings which you need to configure before recovery.
Start Recuva. Enter Advanced mode if the Wizard launches.
Click Options.
In the Options dialog box, click the Actions tab.
Click Scan for non-deleted files, and then click OK.
Run the Recuva scan as normal. Non-deleted files are indicated with a green double-circle status icon.
Hopefully, you will find your corrupted file in recovered files as it recover multiple versions for that file.
Very useful question. I got issue of file crash on sudden shutdown of my PC. recovered file using "Recuva"(download link: https://filehippo.com/download_recuva/) software. Scan for non-deleted files was helpful.
I got help from: https://www.samnoble.co.uk/2014/11/30/visual-studio-crashes-and-a-corrupted-cs-file/
Well, that happen recently for me and I did get my file back this way.
1. Find the project DLLs in the bin folder. Example MySolution.dll
2. Download and Install .Net Reflector from https://www.red-gate.com/products/dotnet-development/reflector/trial/thank-you
3. Open the .Net Reflector app and click the open folder icon then move to your bin directory and select MySolution.dll file
4. Then traverse and expand through your namespaces and classes to look into your codes.
5. Have fun!
(I am new to perforce and am trying to avoid getting myself into problems, I have hit problems doing this with other source code control systems)
When I rename I class I need to
Change the class name it’s self
Get Visual Studio to Refactor all the code that uses the class
Rename the file in the Visual Studio project
Rename the file in Perforce
Check the changes into perforce
Then maybe merge the change from my working branch into the main branch
What’s the best way to do the above with perforce? What issues to I need to be aware of?
This is a multi-step process unfortunately. What you need to do move it first using resharper and then move it again using perforce.
This is how I do it (in Perforce 9.2 and above):
First, checkout the files in Perforce. This will clear the readonly flags for those files and let Resharper modify the files as part of the move.
Use Resharper's Move refactoring and move the classes to the new directory.
The previous step also moved the files from the old folder to the new folder. So now we have to fix that so we can do also do the move operation in Perforce. Use Windows Explorer (or whatever is your favorite tool) to move the files from the new location back to the old location.
Go to Perforce and using the Rename/Move context menu to move the files. This will create a pair entries in the changelist for each file; the first entry is for deleting the file from the original folder and the second entry is for adding it to the new one.
If you have a new enough version of Perforce, it now supports the move command, which will maintain file history across different names. If this is available, your steps are straightforward and should work just fine (from the Perforce side; I'm less experienced with VS).
If you don't have the move command available, you might want to look at this question for a further discussion on renaming/editing files in Perforce.
Have you had a look at the Visual Studio integration (P4SCC) that's available on the Perforce products page? I'd assume that it supports a rename rather nicely (disclaimer: I'm not using Visual Studio with Perforce myself, so I might be wrong).
I have written a macro for adding a "p4 move -k" action to Visual Sudio's Rename event.
See answer of "How to keep change history while renaming files in Visual Studio using Perforce".
With that macro you can do at least steps 3 and 4 at once by renaming file in Visual Studio.
This is kind of a usability question for using VS2005: I have different branches of the same Visual Studio 2005 solution checked out from version control. The solution and project files are also under version control. On my development workstation, I sometimes have multiple instances of Visual Studio opened on a different version or branch each. They all show up under the same name in the window title and the taskbar, which makes it hard to switch to the correct one etc. (The same goes for the list of recently opened projects in the startup page, but I rarely use that, anyway.)
I tried to find a way to only change the name displayed while not running into too much trouble with source control, but Visual Studio 2005 seems to take the solution name from the name of the SLN file itself, not from some attribute inside of it.
It would already help to have Visual Studio show the full path to the solution file in the title bar, but I haven't found a way to do that, either.
How do you handle different versions from the same solution?
Use the (free) VSCommands plugin:
http://geekswithblogs.net/deadlydog/archive/2011/04/29/friendly-visual-studio-solution-names-for-branches.aspx
I guess it only works when using different folders for different branches (not SVN switching), but still, it's good stuff.
Same issue here. VS has bad support for equally named solutions in different directories.
A somewhat hacky workaround: http://www.helixoft.com/blog/archives/32
There's an ideal extension for your problem, but you must use at least VS 2010:
http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6
It changes the title bar, so must not rename solutions or files.
I know that is an old post, but perhaps you have now a newer VS version :-)
Why don't you rename the solution file on your branches, e.g. MySolution-branchXY.sln?
Update:
I'm not sure I understand your comment.
As soon as you have branched your solution, you have two independent versions of each file: one on the trunk (or source branch) and one on the new branch. The two files simply share a common history, but you are free to change them independently on both branches. So you can rename the solution in your branch.