locked
Deploy Package to VS2012 Exp Hive RRS feed

  • Question

  •  Hi all,

    Currently We can devloping our package in VS2010 and deploy it to VS2012 exp hive using the way metioned http://blogs.msdn.com/b/dsvst/archive/2010/03/01/dissecting-vs-2010-package-registration.aspx.

    The solution works but quit slow, Devenv /setup for VS2012 take long time to go. Anybody knows what the fact behind the MSBuild script of building and deploy the VSpackage project to make this task easier? Is there a faster workaround for that?

    Thanks in advance

    Yi

    • Changed type Li Yifeng Tuesday, January 8, 2013 2:09 AM This is a question
    Monday, January 7, 2013 9:34 AM

Answers

  • Oleg, they are trying to install the VSIX to an Experimental Instance of 2012 while they built it in 2010. Their project will not deploy to 2012 as it targets 2010. They could update their project for 2012, but assuming they aren't going to do that then they would manualy need to install it into the Experimental Instance as that isn't a normal deployment scenario (i.e. create on 2010 then install into 2012 Experimental Instance).

    I believe the build process uses the undocumented /updateConfiguration. Note that it is undocumented and thus any release can eliminate it (so don't rely on it, though if you are just developing on a shipped version and it works, then it should continue to work on that version barring removal in a VS udpate, which seems unlikely). That said updateConfiguration does NOT do everything /setup does, which is why it is much faster. It will cause a pkgdef merge on next launch and it will rebuild your command UI on next launch, it will NOT install templates.

    Ryan

    • Marked as answer by Li Yifeng Tuesday, January 8, 2013 2:19 AM
    Tuesday, January 8, 2013 12:34 AM

All replies

  • You shouldn't need to run devenv /setup when using Visual Studio Extensibility projects that produce VSIX packages. It's a simply file copy to the experimental hive automated by the VSSDK targets file. I would recommend creating a new Visual Studio Package project to see how it is done by default in the current version and then converting your current project to a VSIX and use .vsixmanifest and RegistrationAttributes instead of hand-crafting the pkgdef.
    Monday, January 7, 2013 5:27 PM
  • Oleg, they are trying to install the VSIX to an Experimental Instance of 2012 while they built it in 2010. Their project will not deploy to 2012 as it targets 2010. They could update their project for 2012, but assuming they aren't going to do that then they would manualy need to install it into the Experimental Instance as that isn't a normal deployment scenario (i.e. create on 2010 then install into 2012 Experimental Instance).

    I believe the build process uses the undocumented /updateConfiguration. Note that it is undocumented and thus any release can eliminate it (so don't rely on it, though if you are just developing on a shipped version and it works, then it should continue to work on that version barring removal in a VS udpate, which seems unlikely). That said updateConfiguration does NOT do everything /setup does, which is why it is much faster. It will cause a pkgdef merge on next launch and it will rebuild your command UI on next launch, it will NOT install templates.

    Ryan

    • Marked as answer by Li Yifeng Tuesday, January 8, 2013 2:19 AM
    Tuesday, January 8, 2013 12:34 AM
  • You're right, I didn't notice that. Perhaps instead of figuring out how to deploy from VS 2010 to VS 2012 experimental hive it might be easier to update the solution so that it can be opened in both versions of Visual Studio. So instead of importing

    <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets"/>
    

    the projects would use $(VisualStudioVersion) and import

    <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\VSSDK\Microsoft.VsSDK.targets"/>
    
    That way it should be possible to debug the package under each version of Visual Studio.
    Tuesday, January 8, 2013 1:21 AM
  • Yep, they would also need to update the launch target since F5 in package projects are hard coded to a path of VS (i.e. the path of VS in the version it is loaded). I don't believe .user files, where the TargetApplication is stored can take environment variables, or even MSBuild variables, but you can move those items into the primary .csproj file where you CAN use such things, and use that to cause it to intelligently choose the right deployment + launch configuration. Though that assumes you have both 2010 and 2012 on the same machine.

    Ryan

    Tuesday, January 8, 2013 1:24 AM
  • Thanks Ryan and Oleg.

    Currently we are not plan to build our code from VS2012, but the solution should be targeted to both VS, therefore using $(MSBuildExtensionsPath) may not be what we are looking for.

    I will try /updateConfiguration, it sounds better.

    Yi

    Tuesday, January 8, 2013 2:02 AM
  • Hi Ryan,

    /UpdateConfiguration works well on my side.

    Meanwhile it also resolve my another issue, which I mentioned in http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/d9206217-a50d-4f9b-8e28-20e9a61a5c6f/,our colorable items get working if we use /UpdateConfiguration for exp Hive.

    I believe we can close this thread now. Could you take a look that issue?

    Thanks a lot.

    Yi

    Tuesday, January 8, 2013 2:18 AM