Is there a file somewhere that I can use to do massive changes to the context menu in an easier fashion?
The GUI:
gives me no way to move a command from one menu to another, nor does it let me see what the command actually is (in order to add that same exact command to another menu), thus I don't have much to work with.
And thus I am seeking a file (or a gigantic registry key? ugh.) that I can edit somewhere else where I have more powerful tools. (my VS version is Enterprise 2017 if that matters)
You can find the defaults at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Profiles, with a general settings and some language-specific overrides. There's an additional override in IDE\VC\Profiles as well.
In my case, I wanted to move 'Start new instance" on a Project into the top-level context menu. So I:
Made a copy of CurrentSettings.vssettings
Added a new command where I wanted it (via the Tools > Customize... GUI)
Found the command I wanted to clone and moved it up one
Closed VS (it saves on exit)
Compared the two files to find the diffs (use your favorite tool.) You'll find them under Category[#name="Environment_CommandBars"]\CommandBars\UserCustomizations as add remove and modify entries
Took the Cmd attribute from the moved entry and pasted it over the added one (it was Cmd="{1496A755-94DE-11D0-8C3F-00C04FC2AAE2}:00000164" for me, to save interested parties a few steps)
Undid the move to retain only the added entry
I wasn't able to find a command entry for this anywhere in the defaults, so had to figure it out the hard way.
Related
in InstallShield 2011, I cannot modify file permissions under Application Data -> Files and Folders. Whenever I right click on items, it shows grayed out menu buttons. I can't even delete existing entries.
In a bat script later in the installer, I can't copy over certain files because I don't have the right permissions so the installer fails when trying to reference files in BackupFiles. For some reason all the other files get copied over just fine; I can't modify those file's permissions either. I read online that you have to click the "Properties" button in that context menu to change permissions.
My version is InstallShield 2011 Premiere Edition Version 17.
I don't understand why this is grayed out. The source files do not have any restrictions on them so it must be the installer doing something related to permissions.
That boxy orange overlay on the folders and files indicates that these are coming from a Dynamic File Link. Because these files aren't actually added to your project, not all configuration options are available. You might have to edit the permissions on the source files (before build), or change your project to statically include all or some of these files. Given the size of that tree, changing it all to static could be a bit tedious. Changing parts of it (by editing the link exclusions) might be a good middle ground.
Or you could better determine what's going wrong and see if you can address it in the batch file. Assuming this is InstallScript (rather than InstallScript MSI), the entire setup along with any processes it launches should be elevated. So I'm having a hard time guessing what could go wrong. Perhaps a read-only flag? Perhaps use a tool like process monitor to get more information on that, and see if you can add a call to attrib -r, or cacls, or whatever.
Context
I am using VS 2015 and TFS as my version control. I do know how to get a history for a particular source file, and also know how to see in editor the picked version of that file.
Question
In the current version of a particular file I read a comment say
// This is a comment
I would like to find in which commit was that line committed. The obviuos solution is opening history, then the different versions of that file starting from initial commit, and searching for the text in the editor window until a looked text is found.
Is there any convenient solution for that?
Right-click inside the open file in Visual Studio, on the interesting line, and choose Source Control (bottommost menu) and then Annotate.
You'll see the file with changeset information along the left edge.
Note that this will only easily give you access to how the current file came to be, if you wish to dig through annotated historical versions it becomes a bit more cumbersome.
We are slowly moving projects from old file based storage (don't ask) to tfs. Our coders are still used to find the code in the file System.
Since we are talking about 100 Projects each with some sort of history, we have to move them carefully one by one. Resulting that we will have to live for some time with the already existing file structure mixed with the TFS managed files.
To make life easier for our coders, I would like to create a shortcut in the filesystem, for each project that we moved. So the developers can look up if the Project has already been moved, and if yes, go by double click to open up the TFS Source Control Explorer pointing directly to the correct Project.
Is this possible? Thanks for your Response.
I found a simple solution for my needs, which is based on a small batch script, that you'll have to click. It's not a shortcut so to say even though you can still create a shortcut of the batchfile.
Here's the script:
CALL "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat" x86
REG ADD "HKCU\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Explorer\<GUIDofTFS>" /v "SceMostRecentPath" /d "$/<PathToTfsProject>" /f
devenv /Command View.TfsSourceControlExplorer
In fact I combined 2 ideas found in separate sources:
1. Start VS with Source Control Explorer
2. Manipulate Registry to open Source Control Explorer in a specific path
With the command devenv /Command View.TfsSourceControlExplorer you can actually start VS and automatically open Source Control Explorer. Unfortunately there is no way to give a parameter to point it directly to a location you wish. But I noticed that VS2010 seems to persist the last used path and reopens to that place on restarts. A quick research resulted in the registry entry
HKCU\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Explorer\058104ed-f0e2-4126-9ccc-0e37e19c4f91\SceMostRecentPath
By manipulating the value of SceMostRecentPath you can trick VS2010 to open Source Control Explorer with the path in there.
Keep in mind: You will need to replace 058104ed-f0e2-4126-9ccc-0e37e19c4f91 with the GUID of your TFS Installation.
Since we are all using VS 2010 but the installation paths differ, I implemented the path dynamically by making use of the VS100COMNTOOLS variable. First we set up the TFS command line environment:
CALL "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat" x86`
Then we change the registry:
REG ADD "HKCU\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Explorer\[PutYourTfsGUIDHere]" /v "SceMostRecentPath" /d "$/<YourTfsPath>" /f
Finally we do a simple call of devenv.exe with the source Explorer command:
devenv /Command View.TfsSourceControlExplorer
Until they're mapped to a local file path, I don't think this is possible. Though there might be an undocumented way to craft a vstfs:///VersionControl/LatestItemVersion/{itemid} link that might work, I haven't been able to craft one that does the trick.
You could create a powershell script that would check for the local mapping, otherwise ask them where they want to put it and setup the mapping, do a get-latest and go from there...
A bit of trickery with the tf commandline should get you pretty far.
tf workspaces /owner /collecion /computer to see whether there's a local workspace to the right team project.
tf workspace /new /collection to create one if needed
tf workfold /map to create a folder mapping, you could prompt them for a target location
tf get to fetch the latest sources.
Place the .ps1 file in the folder and when opened check for the workspace, if it's there open the local files in the mapped folder. if it isn't, go through the workspace mapping process by invoking the right commands.
I'm using Visual Studio 2010 with VisualHG and TortoiseHg. I've noticed that if I move or rename a file using the Solution Explorer, a little [R] appears next to the file, which I assume indicates "renamed". However, if I go to commit my changes in TortoiseHg, it doesn't perform a rename--it deletes the old file and adds the new one. This causes all the history for the file to be lost (and bloats the repo unnecessarily).
Is there any way to get this to work properly? There's really very little benefit to using VisualHG if it's not going to coordinate file renames properly with TortoiseHg.
Also, I should mention that TortoiseHg has a "Detect Copies/Renames in Solution" dialog, but I can't seem to get it working. First, I can't seem to find any button or menu item in the TortoiseHg Workbench to launch it. Second, if I launch if using the terminal by entering thg guess, no path appears in the Unrevisioned Files box (and there's no apparent way to add one). I made sure I was navigated to the correct directory (my solution directory, which contains my .hg repo) when I tried this. I also tried thg guess solution_directory_path, but that made no difference. If this dialog is a possible solution to my problem, how do you actually use it?
Edit
I finally figured out that you can access the "Detect Copies/Renames in Solution" dialog by right clicking the solution folder in Windows Explorer, and selecting TortoiseHg > Guess Renames. When I do this, however, again, no path appear in the Unrevisioned Files box, so I still can't get started with this dialog. (I.e., I can't even perform step 1 in these instructions.)
Edit 2
I found a bug report on the VisualHG CodePlex issues page that I think explains the problem I'm having: https://visualhg.codeplex.com/workitem/99. I'm kind of surprised it hasn't gotten more votes, though.
After further investigation, I realize that, even though the files were shown as removed/added in TortoiseHg Workbench, they in fact were renamed correctly.
If you click a file with a "+" next to it in the Workbench, if that file was in fact a rename, the header for the code window will show something like this:
Project/Folder/RenamedFile.cs (renamed from Project/Folder/OriginalFile.cs)
After reading a bit more about what Mercurial is really doing, it sounds like it actually is deleting and adding, it's just that the added file maintains a reference to the original, so you can still view the history across renames.
I'm not sure if this explains the problems I was having with "Detect Copies/Renames in Solution", but I'm now satisfied that renames are being handled properly.
I moved some code from my c drive to my d drive. When I opened the solution, it told me that:
The solution appears to be under source control, but its binding
information cannot be found. Because it is not possible to recover
this missing information automatically, the projects whose bindings
are missing will be treated as not under source control.
So I tried permanently removing the bindings and downloaded the latest version. Now my changes don't register as pending changes.
I've tried selecting the solution in the Solution Explorer and File => Source Control => Change Source control, but it does not let me bind. Server Name and Server Binding columns have "".
Generally speaking, the location of code on your machine is dependent upon where your workspace is located.
If you move your workspace to the D: drive, then there shouldn't be an issue.
However, if you simply used Explorer to copy the files to the new location, then VS isn't going to be able to maintain the bindings.
From the Workspace Editor you can map the entire tree, solutions or even individual projects to a new location.
First off, put it back and undo the changes.
Then, Go to File | Source Control | Workspaces.
Click on the work space name and then the "Edit..." button.
In the working folders area select the source control folder you want to move and give it a new local folder location.
You will need to edit your Workspaces for TFS Server to know the change that has happened at your local machine. To edit your workspace, in Visual Studio:
ensure you have no pending changes; also copy your source code folder to some location temporarily, just to be safe (you can remove after you are all set)
go to Source Control Explorer
locate the "Workspace:" dropdown
select the item "Workspaces" from the dropdown list (you will get a dialog titled "Manage Workspaces"
if you have multiple Workspaces, select the appropriate one from the list in the dialog
click on "Edit" button (you will get an "Edit Workspace..." dialog)
down below in the dialog, you will see "Working folders" grid
click on appropriate row from the grid and modify the "Local folder" path to set to your new folder location
Sometimes TFS and Visual Studio have issues in getting these workspace changes synchronized. I would always close Visual Studio and re-launch it to get my changes synchronized anytime after I make Workspace related changes.
Hope this helps.
the most crude way here (I don't know if there is any other way)
is to put the folder back to its old location , Check in your changes
then remap the project to the new folder
When you move files/folders to make the moves pending changes you need to use a TFS client to do the moves.
For one or two files the Team Explorer UI is OK, for more the command line is easiest.
See tf.exe rename on MSDN (tf move is an alias for rename). There is also step by step help on using the GUI: Move, Rename, and Delete Version-Controlled Files and Folders.