I'm working on an MSI Installer project. I would like to add an action to an existing file extension that will be available only from the context menu, while keeping the current default action as is. For instance - add an "Edit with my program" action to a .jpeg, while double-clicking a .jpeg will still open it with the default viewer and not with my application.
When I create a file extension association in InstallShield 2013 Limited Edition for Visual Studio, it makes my action the default one. I don't see a way to change that.
I've also tried to edit with Orca the Sequence of the command in the Verb Table to 9999, to no avail.
Can anybody please tell me how to do that with InstallShield 2013 Limited Edition or with Orca?
Related
Add-Migration generates new files but doesn't include them into TFS source control - they are invisible for Check-in operation and are shown without lock sign on Solution Explorer.
Is there the way to solve it?
P.S. This all happens in project Sdk="Microsoft.NET.Sdk" style. The question can be asked in more wide form: is there a way to "pick up" new files (created without Visual Studio) and include them to TFS automatically?
Have you added the project/solution to source control? You need to add the solution to source control first, after that the new generated files will be detected automatically within the workspace.
Tested on my side and cannot reproduce this issue. Could you provide a sample project for further troubleshooting if that still not work?
I'm using TFS Server 2010.
In my source I have a folder called BuildProcessTemplates. This has a child folder called Custom Assemblies.
Now, when the build runs, it happily loads the DLLs in the Custom Assemblies folder and does its thing.
I need to modify the .xaml file that defines the workflow of the build. If I double click on the .xaml file VS tries to open it but throws an error saying it can't find certain types that I know are defined in the DLL that is in the Custom Assemblies folder.
The workflow is told where to find these types when the build runs by Build Controller as it is defined as a property in the TFS Admin Console.
So, how on earth do I get VS to open my .xaml file properly? How do I let it know where to look for the DLL? I've tried moving all of the files in Custom Assemblies in to the same folder as the .xaml file, but that didn't help.
Clearly I'm missing something; I just don't have a clue what it might be.
You normally create a C# Project (Unit Test is easiest because it is pretty bare).
When you have you project you then need to:
Add the XAML as a File,
Add the Custom Activities DLL's as references.
Add the relevant TeamFoundation* references from the GAC (make sure the TFS version matches - 2010 = v10, 2012 = v11).
Also, I always open our TFS "Build Project" with VS version that matches our TFS Version, I find it keeps the number of problems down.
There's a great series of posts from Ewald Hofman here, that go through the process - I find it a bit dated, and that the Wrox Professional TFS 2012 book does a better job of explaining it, if you can get a copy.
VS2012 seems to remove the popup window for TFS check-ins that was in VS2010. It now seems to take over the team explorer tab in my sidebar, and buries the important things - like which files I've changed. Is there any way to return to a normal popup window for check-ins in VS2012?
For me, the best solution is based on iSid's answer: to add an external tool that pops up the old dialog.
You can do this from Visual Studio: TOOLS -> External Tools… -> Add, with the following values:
Title: Checkin (or any name that should be displayed in the menu)
Command: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\TF.exe (this is the default VS install location on Windows x64)
Arguments: checkin
Initial directory: $(SolutionDir)
Here is a screenshot:
You can invoke from TOOLS -> Checkin (or even assign a keyboard shortcut to Tools.ExternalCommand* as described here) and enjoy the old goodies with a new style:
Note that this won't work if a solution is not opened, because of the $(SolutionDir) variable. To workaround this, you can hard-code the path to your workspace instead.
Additionally, tf.exe can be invoked with 'shelve' argument, which will show the old-style shelving dialog.
Use tf checkin command from Visual Studio command prompt and you will get the same old checkin window.
While the Pending Changes window is merged within the Team Explorer, the Solution Explorer allows filtering by what is pending to be checked in. In addition Open Files filter could also be applied. When the Pending Changes filter is applied, all or some of the files could be selected and right clicked and then there is an option to do the check in. That command takes directly to the Team Explorer in Pending Changes view. See below...
Another method is to use the Productivity Power Tools. This extension adds Windows shell integration so you can perform most of your TFS commands directly from within Windows without even having Visual Studio open. The Power Tools uses the old style windows when used from within Windows shell.
I think the easiest solution is just docking the Team Explorer tab as tabbed document (using the right-click menu). That way it will be equivalent to the popup dialog.
Let's consider this scenarion: In case that I sinchronize my local folder with latest version at Team Foundation Server 2010 and after that manually delete some local file. My question is how I can force TFS to show me Missing files? (Source Safe would show Missing files in this case) For now, TFS check only file versions (not data) and if there is no change it doesn't make any other actions. In this case there is no version change and it doesn't recognize need for action.
You can perform a get specific version and check the option to download all files even if they match (second option).
See http://msdn.microsoft.com/en-US/library/ms181387.aspx for more information.
Good advice from Robaticus, you can also use the TFS power tools. You'll need to select a cutom install and make sure that explorer integration is checked.
This will add a new item to your context menu in windows explorer called "Team Foundation Server" you can use this to get latest, move and delete files. This will save the hastle of opening up Visual Studio when you just want to make a simple edit or delete.
Get out of the habit of using the file system and Windows Explorer to manipulate files. Use the Source Code Explorer to delete them. Otherwise you'll run into problems in the long run.
I'm having a hell of a time trying to get a custom policy to install on TFS2010 using VSIX.
I have the policy up and running and working fine on my development PC, I have written a value to the registry manually, and the policy is enforced.
The trouble is setting up a VSIX project and deployment to our other development machines.
I followed the instructions in:
http://blogs.msdn.com/b/jimlamb/archive/2010/03/31/how-to-implement-package-and-deploy-custom-check-in-policy-for-tfs-2010.aspx
The preferred method appears to be to use the new VSIX project type in VS 2010, I add a VSIX project to my solution, but the instructions in the blog entry are very vague about what to do next. My understanding is that the PKGDEF file means you do not have write a value to the registry when deploying, and the content of the PKGDEF file is rolled into the config when you start Visual Studio. That's fine, but how do you build up the VSIX package?
I tried adding the custom policy project to the VSIX project as a VS Package type, but when I build I get the error: The target "PkgdefProjectOutputGroup" does not exist in the project.
I have tried adding just the dll, the pkgdef file as a custom content type, etc, but nothing works.
I have changed the PKGDEF file in the blog to match my own project.
When I install the VSIX package on a development machine, I can see the add-in in the Extensions Manager in Visual Studio, but when I check the custom policies in TFS, I get the "is not registered" error.
I really need a step-by-step to setting up a VSIX project to deploy a custom policy, can anyone help?
The blog post definitely has a missing step. I think what the author intended was that you add the pkgdef file to the VSIX project (via the vsixmanifest editor) as Content of type VS Package. Then, add a project reference to the checkin policy project from your VSIX project (which will cause the checkin policy DLL to be added to your VSIX).
As a side note....when you pick "VS Package" as the content type and then point to a project...it needs to be a proper VS Package project (not just a vanilla C#/VB class library).
The problem is the assembly name "NArrange.CheckinPolicy.dll" does not match the name in the Policies.pkgdef. To correct this make sure that your Policies.pkgdef looks like this:
[$RootKey$\TeamFoundation\SourceControl\Checkin Policies]
"TeamFoundation.Samples.CheckinPolicies"="$PackageFolder$\NArrange.CheckinPolicy.dll"
Additionally I would avoid further confusion by changing the "Product Name" in source.extension.vsixmanifest to NArrange.CheckinPolicy. This way the assembly will match the product name in VS Extensions.