Is it possible to automatically check a file into Visual Source Safe after the local (working) copy had been changed? Our current process involves editing our code on Windows computer that are running VSS Explorer and after a check in VSS shadow copies the files to the devel Linux server. We're spending a lot of time manually checking the file back in through VSS and would like to just have it push every time we save the files.
Thanks,
Why not write a small app that monitors the folder for updated files, and when they are updated, open your VSS connection and checkin to VSS via a specified or hardcoded path? Just an idea though. I believe you can use something such as FileSystemWatcher. http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
Related
Is there any way to retreive a VS project i opened on my computer from a usb stick.
I don't have the poject on my laptop and i lost my usb stick. I still see the project on the recent project list on VS's start page.
Opening a project from a remote disk does not make a local copy of it. You would have had to have done that manually. If you didn't make a copy, and you have lost the disk, then you are unfortunately out of luck.
The shortcut in the recent projects list is just that—a shortcut. It points to the file on the remote disk. If you clicked on it, it would try to load the solution from the disk, fail to find the disk, and present you with an error message.
This is a good reason to use source control and back up your code to multiple locations.
This is a longshot but if you have the compiled DLL and/or EXE files on your local machine, you can get the source code (or most of it) out of there by using a tool like Telerik JustDecompile.
I haven't been able to determine a pattern, but I keep losing data connections I've added in the Server Explorer.
I have a set of about 20-25 databases I connect with regularly, so I set them up in the server explorer so I don't have to do it each time I open the IDE.
How can I either prevent this loss, or automatically re-add them so I don't have to manually do this every time VS loses them?
I don't remember where I found the information (I'm pretty sure it was stackoverflow, though) but here is what I have done.
I open Visual Studio with no project.
Go to server explorer and add the databases
CD to C:\Users\\AppData\Roaming\Microsoft\VisualStudio\12.0\ServerExplorer
Make a copy of the file DefaultView.SEView
Then, if ever I lose any, I can just copy my backup over the DefaultView.SEView file and they are all back.
Subsequent to UPDATE 4, the SEView file must be recreated, then backed up again as above. Still not sure why the file gets lost when it does.
I made some code changes (in VS 2010), and did not check in or shelve my latest changes. Unfortunately, my laptop had a heating problem and I can't use it for another week (it's going for service). I have the hard drive with me though, so I can probably access the code from another machine. But how do I do it without messing up the state in TFS? If I copy-paste all my code from the hard drive into the other machine, VS will check out all my files right? Is there a better way to do this?
Thanks!
I would check the files out that you think are changed (you can use a tool like WinMerge to see which files have changed), copy the updated files from the old drive, and shelve or check them back in.
If the files are in a solution and you have the complete structure on your disk try if the "Go online" feature is available if you open the solution.
"File => SourceControl => Go online" or go to another machine and map your workspace to your disk with the changed source code.
(I would create a temporary private workspace for that situation and delete it after successfull merging/checkin).
I suppose if you open the solution and it has a valid source control binding, you get a message that your solution is right to go online.
If this dialog appears select "yes", all changes are correctly detected and you can merge/checkin in the normal way.
On the new machine get the latest code from branch, which comes with previously checked-out TFS version by you, then copy/paste the files from harddisk to replace tfs verison.
2 projects under TFS Source Control.
DependancyProject.sln
AppProject.sln
With AppProject referencing DependancyProject.
-
The issue I have is with an Installer project in the AppProject.
It has DependancyProject.dll as a 'reference'(?) where it tries to include it in the GAC.
When I try to build this project, to create an MSI to install the App, I get the error
The item $/Assemblues/DependancyProject/bin/debug/DependancyProject.dll is locked for check-out by USER in workspace HIS-PC-NAME.
(The PC in question is not dead and not used)
The dll is not (as far as I can see) checked into Source Control.
The path it references anyway does not exist when I browse through it (no bin folder).
The DependancyProject is refernced by pretty much every project in Source Control, and i've never had any issues with it.
It builds, all the other projects build.
It's just this one Installer Project which doesn't.
And I can't see why it would need to try and modify it anyway.
All it needs to do (I'm assuming) is make a copy of it.
Any ideas here?
Some files are configured as "non-mergeable" in TFS, which means that they'll be locked when changes are pended on them. The default list includes a variety of binary files, including .dll files. Note that this lock applies to all pending changes - including adds.
It's likely that the other developer in question accidentally pended adds for his bin directory - and any binary files in that directory (ie, most of them) would have been locked as well due to being in that unmergeable list.
You will not be able to pend other changes (including an add in a different workspace) while these items are locked. To break this lock, the other developer can do this by undoing the pending changes, or a server administrator can do it using the Find in Source Control functionality in the Team Foundation Server Power Tools.
That said, I don't know why your build process is trying to pend an add on that file.
I had the same problem, and this guide solved all my problems.
The file was actually locked by me, but in a different work space (old computer).
Had to use the tf undo command to unlock the files.
If you are not going to use that workspace again, you can delete it by going to workspace pull down, selecting workspaces, and enabling the check box "Show remote workspaces". you can then select it and remove it.
SourceSafe Related Error message I got in Visual Studio 2010 when I tried to edit a file:
File is already checked out by the current user in a different location
Background:
For some reason source safe saved the files 3 directories deep.
For Example, The solution files were located in: VS2010Apps\CCP_Utility\CCP_Utility\CCP_Utility\
The solution files should be in the root directory: VS2010Apps\CCP_Utility
I moved the files to VS2010Apps\CCP_Utility to create this error and now I can't edit my project....
Question:
How can I edit my files again and keep the correct directory structure???
Do I Just delete the source safe files and re-add it to source safe or what?
It sounds like VSS is expecting those files in a particular directory. To solve this:
find and make the path that VSS is expecting; the one with ccp_utility x 3.
check-in (all files) to VSS.
if you don't care about version history at this point, delete the project from VSS.
disconnect/unbind your solution from version control.
make the directory layout on disk as you need.
drag & drop the root folder of your new layout on disk into VSS Explorer. Suggest make it a brand new path (aside your old project) in VSS, to avoid any complications.
you now have a 'new project' as far as VSS is concerned.
ensure your bindings are correct, and you should be able to continue as per normal.
This happened to me when my work machine was replaced and I had forgotten to check in some files on my old machine before the change. My local copy of the file was the one I wanted to work with, but VSS had it marked as checked out on a different machine [my old machine].
I just opened the Source Safe Client, browsed to the affected files and checked them in: the client asks if I wish to proceed using the local file (Yes) - then just reloaded the project in Visual Studio.