Deploying Custom Policy on TFS2010 using VSIX and PKGDEF

Question

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?

Overline

Do you have the Visual Studio SDK installed? – Crookback

Yeah man! Of course! How could I create a VSIX project without it? – Overline

Great. Did you change any of the class names or the namespace? If so, you'll need to update the registration type info accordingly. – Crookback

Jim, I'm afraid you've lost me a bit there. After any changes I recomplied everything and rebuilt the VSIX, uninstalled the old version of the extension and then reinstalled the freshly compiled version. Surely that would update any necessary reference info? – Overline

Answer 1

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).

Extravascular

If I search my C drive for the pkgdef file, the only copies I can see are those in my development folder - you would expect to see this file deployed to a visual studio extensions folder or seomthing right? Am I missing another step? One other question - is the pkgdef file in the article the complete file, or just a snippet? Does the pkgdef file need to be generated with a tool, or can you just copy and paste the code sample and modify it for your own needs? – Overline

Ahhh...one step I forgot to mention. Did you set the pkgdef file to Build Action=Content and Include in VSIX = True (Properties window)? You should see it in under %LocalAppData%\Microsoft\VisualStudio\10.0Exp\Extensions when you debug your VSIX. You should be able to just use the snippet from the blog post. – Extravascular

Aaron - thanks, yeah, I have those properties set on the pkgdef. After I click on the VSIX package to install it, it installs with no error and I can see it in visual studio extensions. BUT, when I search my C drive for the pkgdef and the dll, they're only in my development folder - should they be copied somewhere by the VSIX on install? If so, how do I instruct the VSIX to do that? – Overline

VSIX is just a zip file. If they're in the file, they'll get installed. By default, VS extensions will install to %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions. Do you have a subfolder there with your DLL, pkgdef, and vsixmanifest file(s)? – Extravascular

Aaron, no, there is no sign of those files anywhere on my hard drive after I install the extension - and yet the extension shows in the extension manager. It doesn't make much sense! – Overline

What is the output of this command (assuming you're running Vista or Win7)?: dir /b/s %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions*.vsixmanifest You should see your vsixmanifest file there (and the pkgdef/dll sitting next to it). The only other possible place Extension Manager would be picking it up from would be somewhere under %VSInstallDir%\Common7\IDE\Extensions. – Extravascular

Aaron, I get "Cannot find the file specified" for both the directory locations you mentioned. What next? – Overline

Aaron, I checked my environment variables, and it doesn't even look like "localappdata" is defined... – Overline

If you're on XP, it will be C:\Documents and Settings\<username>\Application Data\Local Settings. It may be a hidden folder. – Extravascular

Hey!!! I found it!!! That's weird. I guess because it is a "hidden" folder it didn't show in the search on the C drive I did. OK - to summarise: I now know that the VSIX is installing my extension to C:\Documents and Settings\<username>\Local Settings\Application Data. It appears in the Extension Manager in Visual Studio. When I go to add the custom policy to a source control project in TFS (Right click on project in TFS Team Explorer, Team Project Settings, Source Control, Checkin Policy, Add), the policy does not appear in the list of options. What now? – Overline

Assuming you also found a pkgdef (with the matching assembly name of your DLL) there, and that information is being merged into the registry cache after you start VS (HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\TeamFoundation\SourceControl\Checkin Policies), then you've reached the limit of my knowledge. I'd suggest contacting the author of the blog post for further help with TFS checkin policies. – Extravascular

Aaron - Yes, the Pkgdef is in that location, and its name matches the dll file. I start VS, and I do not see the registry key appear in the location you mentioned. Is it supposed to actually physically appear in that location so you can view it with regedit? – Overline

Yes. See this post for more information on pkgdef: blogs.msdn.com/b/visualstudio/archive/2009/12/18/… – Extravascular

Thanks Aaron. I found a useful article at blogs.msdn.com/b/visualstudio/archive/2010/03/22/… that explains how to log out the pkgdefs that do get loaded when visual studio loads up. It looks like pkgdef wasn't loading because of a syntax error - d'oh! I corrected the error and now everything works!!! Amazing. A tiny syntax error was the cause of all this. Thanks for leading me to the article that helped me find the devenv.exe log file, the solution to the problem was laid bare in the log file. Thank you once again. – Overline

Everything's looking good - but I just noticed another little problem. If a user has not installed the extension yet, they get an error message, and the Installtion Instructions are blank - even though I have put instructions into the InstallationInstruction property in the class that inherits from PolicyBase. Any reason why the installation instructions might not show? – Overline

To answer my own question... The property to override is InstallationInstructions, not InstallationInstruction... my bad. So yeah, now I'm golden. – Overline

This process is just baffling - I've been trying all day to VSIX-deploy a custom checkin policy that works just fine if you manually register it on a dev machine. This thread has helped tremendously, but I still can't get it to work. My .pkgdef file, it seems, is not even considered by VS because it's being installed under the $PackageFolder$ (I'm not installing the VSIX machine-wide). This link suggests that the .pkgdef file needs to be in the VS Extensions folder, but how to setup the VSIX to do that? blogs.msdn.com/b/visualstudio/archive/2010/03/22/… – Ketch

And by the way, I do have "Load per user extension when running as administrator" enabled. – Ketch

Ah, I see in the log that my pkgdef is in fact getting loaded as a user extension, but the Pending Changes panel still says "not registered". I see no pkgdef syntax errors in the log, and I see no registry entries show up while VS is running (in the place I'd normally register the policy). – Ketch

Answer 2

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.

Embodiment