none
SDK Package: How do you deploy Integration Package to machine without SDK installed?

    Question

  • I'm having trouble trying to deploy an Integration Package to machines that do not have the SDK installed. Every machine is running 32-bit Windows XP Professional and Visual Studio 2008 with service pack 1, .NET version 3.5.

    I have researched this issue and have only found 2 relevant links:

    http://msdn.microsoft.com/en-us/vstudio/cc627235.aspx

    In this video how to/tutorial Hilton Giesenow describes how to install a package to the experimental hive. All registry keys/values need to be placed under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0Exp\Configuration. He says in order for it to show up in the normal instance of visual studio all you have to do is remove the "Exp" part of the key (HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Configuration).

    That, of course, did not work. I noticed there was nothing under that Configuration key except the stuff I just added so I knew that couldn't be right. I started combing through the registry to find where other packages are registered. Eventually I figured out I need to change HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE and drop the Configuration part. It worked!

    I gave it to someone else to install, it worked for him. I gave it to a 3rd person to install, it did not work for him. I tried it on my 2nd machine and the other person's 2nd machine and it did not work on those either. So 2 machines it worked on, 3 machines it did not work on.

    I figured out the 2 machines it worked on had the Visual Studio 2008 SDK installed, the 3 that it did not work on did not have the SDK installed. I installed the SDK one of the other 3 machines and suddenly my integration package was working on it. Clearly there's an issue with the Integration Package only working on machines that have the Visual Studio 2008 SDK installed. After some more google searching I came across this thread: http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/2b87c576-7e40-4554-b1fd-2255a4feb496/

    It appears to be the exact same issue that I'm having and there's an answer to it. I thought everything was going to be OK. So I included the reference to System.Drawing.Design to my Integration Package project, rebuilt it, uninstalled the package on the 2 machines that it was not working on, and reinstalled with the new dll that included a reference to System.Drawing.Design. Tested it out, still didn't work.

    How can I get an Integration Package to appear in Visual Studio on machines that do not have the SDK installed?

    Wednesday, March 09, 2011 4:38 PM

Answers

  • I don't believe it costs anything, but you need to request one at the link below.

    http://msdn.microsoft.com/en-us/vstudio/cc655795

    PLKs are no longer necessary in 2010 and are free with registration in 2008, not sure about the situation for 2005 and prior.

    Ryan

    • Marked as answer by ColtonGrundy Friday, March 11, 2011 3:10 PM
    Thursday, March 10, 2011 11:54 PM
    Moderator
  • Hi Colton,

    I can confrm, you need a PLK for everything up to (but not including) VS 2010. As Ryan metioned the PLK (and it's isolated shell equivalent (SLK) are no longer required). It's a bit of a hassle, but the documentation does cover this pretty well. Just make sure the values that wind up in the registry, are the same ones you use to apply for the PLK. If they fail to match up, the PLK check will still fail.

    I highly recommend adding it to your package. Not doing so will eventually place a support burden on you (and probably me, as I seem to get most of the support calls when packages fail to load). So please do yourself (and me) a favor, and  add that PLK :-).

    P.S. PLK integration is pretty easy to validate on your dev box (where the VS SDK is installed). Just invoke devenv.exe with the /noVSIP switch, which I believe is covered in the troubleshooting topic above.

    Sincerely,

     

     


    Ed Dore
    • Marked as answer by ColtonGrundy Friday, March 11, 2011 3:10 PM
    Friday, March 11, 2011 1:51 AM
    Moderator

All replies

  • Have you tried running devenv /log on the machines where it isn't working and looking at the resultant ActivityLog to see why your package is not working?


    Ryan

    Wednesday, March 09, 2011 4:45 PM
    Moderator
  • Just tried it and I'm getting 3 warnings that say CheckPackageSignature failed; invalid Package Load Key. But the GUID listed for the package that failed is not the GUID for my package. There is nothing in the ActivityLog related to my package.

    So...according to the log, it's not even trying to use my package? The package does appear under the Help > About screen in the Installed Products listbox, but the menu item is not available.

    Wednesday, March 09, 2011 4:55 PM
  • Well, it means it is not loading your package at startup, which likely isn't a problem, it is by design that we don't load every package at startup as that would result in abysmal perf. Your menu item not being available could be due to a number of issues

    1:  We haven't rebuilt the CTM (merged command table). This normally happens during devenv /setup, since you have installed to an admin location you likely need to run that with admin priveldges.

    2:  You haven't properly registered your package as contributing menu resources.

    You can use VSCTPowerToy to see if, on the machines where your command isn't showing up, we are even aware your command exists.

    Ryan

    Wednesday, March 09, 2011 7:16 PM
    Moderator
  • Is there a VSCTPowerToy for visual studio 2008?

    If the package wasn't registered as contributing menu resources, why would it show up on a machine that has SDK installed?

    Wednesday, March 09, 2011 8:33 PM
  • VSCTPowerToy - 2008

    It wouldn't, but what you describe sounds somewhat 'magical' so I was just throwing it out there. If you mean you seem to need the SDK installed on a machine just to get a basic package install to work properly, that has never been my experience, but then again you are dealing with your own custom installer I take it (from the stuff you wrote above about writing to reg locations) so it is unclear what differences may have occured on the machines where it isn't working.  Are the registration keys for your package present on the 'bad' machines and specifying the proper GUID for your package?  Is the package registeration correct and pointing to the location of your package dll? Are all of your package dll's dependecies located in a place where the CLR could find them?

    Ryan

    Wednesday, March 09, 2011 8:42 PM
    Moderator
  • then again you are dealing with your own custom installer I take it (from the stuff you wrote above about writing to reg locations) so it is unclear what differences may have occured on the machines where it isn't working.

    I added a standard Setup Project (File > Add > New Project... > Other Project Types > Setup and Deployment > Setup Project) and in the Registry Editor I imported the .reg file that I created with regpkg

    Are the registration keys for your package present on the 'bad' machines and specifying the proper GUID for your package? Is the package registeration correct and pointing to the location of your package dll?

    Yes. The GUID specified for my package under the InstalledProducts key is present in the Packages key and the value for CodeBase correctly points to the directory that was chosen during installation. I checked in that directory and my package dll is there.

    Are all of your package dll's dependecies located in a place where the CLR could find them?

    I went through every single reference in my package one by one and each of them (except 1, but that 1 is in the same install directory as my package dll. It should have no problem finding that) is in the GAC (C:\Windows\Assembly) with the correct version and everything on all 5 machines, where it works and where it doesn't work.

     

    I don't think there is really a problem with the package, on one of the machines the SDK was not installed and the package didn't work. We just installed the SDK on it, did not uninstall/reinstall the package just left it on there as it was and the next time we opened visual studio after installing the SDK it worked. I tried running devenv /setup but that didn't seem to have any effect.

    Wednesday, March 09, 2011 9:01 PM
  • Do you have a zip to share that includes your installer so I could look at in terms of installing it on a basic Dev10 install with no SDK and seeing why it doesn't seem to be showing up? Did you check if your command was present in the CTM (installed command table in VSCTPowerToy terminology) on the bad machines?

     Ryan

    Wednesday, March 09, 2011 9:25 PM
    Moderator
  • I do, but I can't upload here, I don't have my own site, and every site I can think of to upload files to is blocked here at work. The only way I can think of to get it to you would be through email.

    I can't figure out how to use the VSCTPowerToy. When I choose the Open Installed Command Tables menu item it's not showing any commands at all. The treeview just has a bunch of empty folders nested inside of other folders with nothing else.

    Wednesday, March 09, 2011 10:35 PM
  • Did it give you any errors on launching?  Have you tried File->Open Installed Command Tables?  If that doesn't work you can locate your CTM (it is a hidden file, normally under ProgramData or your Users subdir, you can find it via dir /A:H /s devenv.CTM, then you need to do attrib -h on it to unhide it so VSCTPowerToy can see it in its Open dialog) and manually load it? 

    Ryan

    Wednesday, March 09, 2011 11:27 PM
    Moderator
  • I did File -> Open Installed Command Tables but nothing happened. I just manually loaded the devenv.CTM file and that worked. The command for my package does not appear on the machine without SDK installed, it does appear on the machines that have SDK installed. I tried running devenv /setup (that's supposed to rebuild the CTM right?) but that didn't fix it.

    I'm not sure if this is something I'm supposed to do or not but I tried opening my package dll in the powertoy and it says:

    Library "C:\Program Files\HistoryExtended\HistoryExtended.dll" was loaded but a resource of type CTMENU was not found.

    The assembly "HistoryExtended, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" does not contain resources with the well known name "VSPackage", trying manifest resources

    Unable to locate resources in the assembly HistoryExtended, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.

    Unable to locate resources in the file C:\Program Files\HistoryExtended\HistoryExtended.dll.

    Command table resources in assemblies must be in VSPacakge.resources and its name must at least end with 'ctmenu'.

     

    Could that be the cause?

    Thursday, March 10, 2011 2:19 PM
  • That does seem odd, but in that case I can't see how it would work on any machine or why installing the SDK would fix it. Can you try deleting the CTM on a machine where it isn't working and then launching VS?

    Ryan

    Thursday, March 10, 2011 3:26 PM
    Moderator
  • I deleted the CTM, launched VS, the new CTM file still doesn't have the command for my package.
    Thursday, March 10, 2011 4:09 PM
  • Hmmm, I am baffled. Having the SDK installed is certainly not required for re-dist, and I have never seen this issue myself and have dealt with a large share of extensions. There is something we are missing. The fact that VSCTPowerToy can't find your resources seems interesting, though I can't explain how the same dll on a machine with the SDK installed would make us magically able to find the resources.  Just to cover all the 'obvious' bases

    1:  You have an entry under the Menus key whose keyname is your package key?

    2:  Are you using the ProvideMenuResources attribute on your package? If so can you paste it here?

    3:  On the machines where it isn't working are you running your installer as admin? After deleting the CTM did you launch VS as admin or normal user?

    Ryan

    Thursday, March 10, 2011 4:22 PM
    Moderator
  • 1: You have an entry under the Menus key whose keyname is your package key? Yes.

    2: Are you using the ProvideMenuResources attribute on your package? If so can you paste it here? No. I've never even seen that attribute before. I just followed the steps in that video in the first link of the original post here.

    3: On the machines where it isn't working are you running your installer as admin? Yes.
    After deleting the CTM did you launch VS as admin or normal user? Admin.

    My project definitely does not have any file with a .ctmenu extension in it. Is it supposed to? I just followed the steps in the video that I linked to in the 1st post. There was no step to create a .ctmenu file and the project doesn't get created with one when you start a new Visual Studio Integration Package project.

    Also, I read that CheckPackageSignature gets bypassed when you have the SDK installed. I know CheckPackageSignature is not the issue in this case because my GUID never appears in the activity log, but maybe there's another separate thing that visual studio is checking for but when you have the SDK installed it skips that step?

    Thursday, March 10, 2011 4:38 PM
  • >My project definitely does not have any file with a .ctmenu extension in it. Is it supposed to? I just followed the steps in the video that I linked to in the 1st post.

    I don't have time to watch the video at the moment unfortunately.  The ProvideMenuResources is simply a way to have the regpkg stuff generated the Menus entry, if you have a Menus entry in after your setup then you are probably fine, assuming the entry is valid.  Can you paste the contents of the entry under the Menus key for your package here?

    The .ctmenu is a resource that the VSCT compiler creates and embeds into your assembly, it isn't present on disk but rather only embedded into your DLL, you can see it if you look at the DLL in .NET Reflector and look at the resources section.

    As for CheckPackageSignature, I know nothing about that or any special cases around what differs when the SDK is installed vs when it isn't. I don't think the menu merge code 'loads packages' it simply loads the dll in question and uses the resource manager to extract the command blob (.ctmenu) and it merges that data with the command blobs from all other dll's that have menus and then saves the result to the CTM file, which is used at startup to build the command UI.

    Ryan

    Thursday, March 10, 2011 6:58 PM
    Moderator
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Menus
    Name: {b5a2ed96-9f1a-4e05-b9a8-ee89177caecc}
    Data: , 1000, 1
    Thursday, March 10, 2011 7:35 PM
  • Okay, so you should have a 1000.ctmenu resource in your dll, I assume you must if this works on some machines. I pinged someone internally to see if there are any checks that may be skipped when the SDK is installed, but there aren't any in this area I am aware of.

    Ryan

    Thursday, March 10, 2011 7:37 PM
    Moderator
  • I opened my dll in .NET Reflector and under Resources I do not have 1000.ctmenu

    I think I just ruined something. I do have a resource called HistoryExtended.VSPackage.resources and inside of that there's a resource named "1000". It is 2493 bytes of type System.Byte[]. Could it be refering to that?

    Thursday, March 10, 2011 8:35 PM
  • That may be fine, I can't recall how the exact packaging of this stuff goes, I do know that there should be a resource named 1000 according to your registration, and if it works on some boxes then it must be there, otherwise it wouldn't work on any box, so we must be discovering it even if it is 'nested'.

    Ryan

    Thursday, March 10, 2011 8:48 PM
    Moderator
  • Yes, I tried changing the registry value to 1111, i disassembled my dll with ildasm and i used a resouce editor to change 1000 to 1111 then reassembled it with ilasm, deleted the CTM file so it would get rebuilt and it still showed up in the correct place with the correct name and icon.
    Thursday, March 10, 2011 8:53 PM
  • Yes I think the probing logic will first look for the registered name (1000 in your case), and if that fails it will look for .ctmenu it can find, but I have never plumbed through that code myself.  Have you tried using the Package Load Analyzer (ships with the SDK I believe) to see if there is some package issue on the machines this isn't working on? The person I pinged said this could be some error around the Package Load Key, but I know pretty much nothing about that area myself :(


    Ryan

    Thursday, March 10, 2011 9:18 PM
    Moderator
  • I can't use the Package Load Analyzer on the machines that aren't working because by installing the SDK they will start working. I used the analyzer on a machine that is working though and looks like there is an issue:

     

     

    ################
    SUMMARY
    ################

    Visual Studio Package Load analysis for package {b5a2ed96-9f1a-4e05-b9a8-ee89177caecc} failed. Following Verification(s) failed:-
    Plk Verification


    Plk Verification:
    Package Load Key(PLK) verification failed for package {b5a2ed96-9f1a-4e05-b9a8-ee89177caecc}.

    Plk verification was based on the following entries in the registry - 
    CompanyName - Company
    ProductName - History Window Extended
    ProductVersion - 1.0
    MinEdition - Standard
    ID - 1


    Dependency Verification:
    Dependencies for Package {b5a2ed96-9f1a-4e05-b9a8-ee89177caecc} were successfully verified.

     

    ################

     

    Ok, that must be the thing I was thinking of before. When the SDK is installed it doesn't check for a Package Load Key, but when the SDK is not installed it does check for the PLK. That's got to be the issue. That's weird, none of the resources, tutorials, videos, or anything that I've looked up said anything about obtaining a PLK from the Visual Studio Industry Partner Web site but I just found that on MSDN library.

    Wow... I wish I knew it would end up costing thousands of dollars to distribute this package before I started coding it. It's not even something I'm trying to sell, just a tool to use internally in our development team to make certain workflows easier.

    Is there any issue with distributing a package internally without a PLK by making everyone install the SDK?

    Thursday, March 10, 2011 10:16 PM
  • I don't believe it costs anything, but you need to request one at the link below.

    http://msdn.microsoft.com/en-us/vstudio/cc655795

    PLKs are no longer necessary in 2010 and are free with registration in 2008, not sure about the situation for 2005 and prior.

    Ryan

    • Marked as answer by ColtonGrundy Friday, March 11, 2011 3:10 PM
    Thursday, March 10, 2011 11:54 PM
    Moderator
  • Hi Colton,

    I can confrm, you need a PLK for everything up to (but not including) VS 2010. As Ryan metioned the PLK (and it's isolated shell equivalent (SLK) are no longer required). It's a bit of a hassle, but the documentation does cover this pretty well. Just make sure the values that wind up in the registry, are the same ones you use to apply for the PLK. If they fail to match up, the PLK check will still fail.

    I highly recommend adding it to your package. Not doing so will eventually place a support burden on you (and probably me, as I seem to get most of the support calls when packages fail to load). So please do yourself (and me) a favor, and  add that PLK :-).

    P.S. PLK integration is pretty easy to validate on your dev box (where the VS SDK is installed). Just invoke devenv.exe with the /noVSIP switch, which I believe is covered in the troubleshooting topic above.

    Sincerely,

     

     


    Ed Dore
    • Marked as answer by ColtonGrundy Friday, March 11, 2011 3:10 PM
    Friday, March 11, 2011 1:51 AM
    Moderator
  • I saw that link for how to obtain a PLK for a VSPackage. It links to http://www.mstoolspartners.com/anonymous/default.aspx and when I sign in there is no link to generate load keys.

    It looks like the http://msdn.microsoft.com/en-us/vstudio/cc655795 link works though. Thanks Ryan and Ed.

    Friday, March 11, 2011 2:23 PM