none
VSIP Integration with Visual Studio 2017

    Question

  • We have been integrating our product with Visual Studio IDEs using the VSIP mechanism. This worked fine until VS2017 where the registry hive had been modified.  Is VSIP still supported in VS2017 ? If not, is there a documentation pertaining to migration path ?

    Secondly, how do I figure out the EnvSdk_Regkey value for VS2017 - 16.0 or 17.0 do not work?


    Vinita

    Friday, March 17, 2017 10:06 AM

All replies

  • We have a VSIP based integration with Visual Studio which all worked well till Visual Studio 2015. With Visual Studio 2017, changes have been made pertaining to registry hive. I would like to know if VSIP based integration is supported with Visual Studio 2017. If not, is there are a migration path documented which we can use ? 

    Secondly, is EnvSdk_Regkey supported in Visual Studio 2017 ?


    Vinita

    Friday, March 17, 2017 10:03 AM
  • Hi,

    What is the "VSIP mechanism"?

    If you are developing a VSIX / package see:

    It’s time to change the VSIX manifest of your extension to v3 for Visual Studio 2017 compatibility

    About the registry change see:

    Some implications of the new modular setup of Visual Studio 2017 for VSX developers


    My portal and blog about VSX: http://www.visualstudioextensibility.com<br/> Twitter: https://twitter.com/VSExtensibility<br/> MZ-Tools productivity extension for Visual Studio: https://www.mztools.com

    Friday, March 17, 2017 5:17 PM
    Moderator
  • Hi Vinita Sanghi,

    According to your description, please share us which type project you are creating? VSX or others?

    If your project is VSX project, VS2017 support VSX developing.

    Sincerely,

    Oscar


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, March 20, 2017 7:05 AM
  • Our integration mechanism uses VSIP (Visual Studio Industry Partner) packages, Our product installer writes to different VS registries, and uses the Visual Studio installation path registry keys to determine which devenv.exe /setup should be run to register the private code base assemblies. These VS packages are in-proc COM objects.


    Vinita

    Monday, March 20, 2017 8:51 AM
  • VSIP refers to Visual Studio Industry Partner Program.

    Our integration mechanism uses VSIP (Visual Studio Industry Partner) packages. The product installer writes to Visual Studio registry hive, and uses the Visual Studio installation path registry key to determine which devenv.exe /setup should be run to register the libraries. These VS packages are in-proc COM objects. With Visual Studio 2017, the registry hive no longer exists. Do we need to migrate to new VS 2017 extension projects or do we need to use registration free activation of COM components ?

     

    Vinita

    Monday, March 20, 2017 8:58 AM
  • You should strive to use VSIX deployment mechanism or at the very least .pkgdef files rather than using a setup that needs to write registry entries directly. If you really need it read the section External processes cannot read Visual Studio 2017 registry entries directly of my post http://www.visualstudioextensibility.com/2016/11/23/some-implications-of-the-new-modular-setup-of-visual-studio-2017-for-vsx-developers/

    My portal and blog about VSX: <a href="http://www.visualstudioextensibility.com"> http://www.visualstudioextensibility.com</a> Twitter: https://twitter.com/VSExtensibility MZ-Tools productivity extension for Visual Studio: https://www.mztools.com

    Monday, March 20, 2017 9:30 AM
    Moderator
  • You should strive to use VSIX deployment mechanism or at the very least .pkgdef files rather than using a setup that needs to write registry entries directly. If you really need it read the section External processes cannot read Visual Studio 2017 registry entries directly of my post http://www.visualstudioextensibility.com/2016/11/23/some-implications-of-the-new-modular-setup-of-visual-studio-2017-for-vsx-developers/

    My portal and blog about VSX: <a href="http://www.visualstudioextensibility.com"> http://www.visualstudioextensibility.com</a> Twitter: https://twitter.com/VSExtensibility MZ-Tools productivity extension for Visual Studio: https://www.mztools.com

    Monday, March 20, 2017 9:35 AM
    Moderator
  • Thanks for the reply. However, we have unmanaged packages which implies that .pkgdef files cannot be used.  Based on my current understanding, we need to follow below approaches:

    1. For the unmanaged packages which are currently being registered using regsvr32 , followed by executing devenv.exe /setup for the Visual Studio version as specified by EnvSdk_regkey, we need to adopt Registration free activation of COM components. As I understand Envsdk_regkey does not hold good any more in VS2017 and we need to follow https://blogs.msdn.microsoft.com/heaths/2016/09/15/changes-to-visual-studio-15-setup/ to get hold of installation path.

    2. For the managed packages, we need to use RegLoadAppKey function to load the Visual Studio 2017 private registry hive - privateregistry.bin, modify the hive to include our changes and then unload the hive. 

    Does this makes sense?


    Vinita

    Monday, March 20, 2017 3:35 PM
  • Thanks for the reply. However, we have unmanaged packages which implies that .pkgdef files cannot be used.  Based on my current understanding, we need to follow below approaches:

    1. For the unmanaged packages which are currently being registered using regsvr32 , followed by executing devenv.exe /setup for the Visual Studio version as specified by EnvSdk_regkey, we need to adopt Registration free activation of COM components. As I understand Envsdk_regkey does not hold good any more in VS2017 and we need to follow https://blogs.msdn.microsoft.com/heaths/2016/09/15/changes-to-visual-studio-15-setup/ to get hold of installation path.

    2. For the managed packages, we need to use RegLoadAppKey function to load the Visual Studio 2017 private registry hive - privateregistry.bin, modify the hive to include our changes and then unload the hive. 

    Does this makes sense?


    Vinita

    Monday, March 20, 2017 3:36 PM
  • Hi,

    Regarding #1, I don't know very much about unmanaged packages, so I can't answer.

    Regarding #2, yes, that's correct. 


    My portal and blog about VSX: <a href="http://www.visualstudioextensibility.com"> http://www.visualstudioextensibility.com</a> Twitter: https://twitter.com/VSExtensibility MZ-Tools productivity extension for Visual Studio: https://www.mztools.com

    Monday, March 20, 2017 5:46 PM
    Moderator
  • Hi Vinita,

    Self-registering components have been somewhat frowned upon for quite some time now. If you're missing dependencies, the components then fail to load and register themselves, leading to all kinds of support headaches.

    Native C++ based packages should be registered via a .pkgdef, just like managed VS packages. If you build a  stock C++ based extensibility package, with VS 2010 or newer, you'll see exactly what goes into a .pkgdef, and how it's included via the .vsixmanifest.

    Note, with C# the .pkgdef is automatically generated at build time, based upon the usage of registration attributes applied to the various objects in the managed package. But with C++ based packages, there is no registration attribute, so you have to add the entries to the pkgdef by hand.

    But once added, you should be able to remove your dependency on self-registration. And given VS 2017's move to using a private registry binary, this would seem to be the easier choice.

    One caveat here though. It looks like the VS 2017 installer fails to register the C++ project template for C++ based packages. The template files are installed, but they aren't properly registered, so the project template for C++ based packages isn't present in the IDE. We've got a bug logged for this, and I'm currently looking into what we can do to manually register the tempate. Will post back here when I get the details figured out.

    Sincerely,


    Ed Dore

    Tuesday, March 21, 2017 1:01 AM
    Moderator
  • Hi Vinita Sanghi,

    This forum is discussing Visual Studio WPF/SL Designer, Visual Studio Guidance Automation Toolkit, Developer Documentation and Help System, and Visual Studio Editor.

    Whether your project is VSIX project? or others.

    Please share us your project style, which could helpful for others to help you further troubleshot this issue. Or I could help you move to corresponding forum for a professional answer.

    Sincerely,

    Oscar


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, March 21, 2017 1:49 AM
  • Hello Ed,

    Thanks for the reply. Please note that our native C++ based packages are being built with Visual Studio 2005. Secondly, when we say "Native C++ based packages should be registered via a .pkgdef," does it implies that registration being carried out earlier using regsvr32 , can be achieved via pkgdef ? Finally as regards the bug submitted for C++ project template for C++ based packages - will it disable registration of native C++ based packages with Visual Studio 2017 ?

    Thanks for the help,

    Vinita


    Vinita

    Tuesday, March 21, 2017 11:15 AM
  • The project is native VC++ packages based on VSIP .

    Vinita

    Tuesday, March 21, 2017 1:54 PM
  • You should be able to add the registry keys required via a .pkgdef file. You'll need to review your C++ code and determine what specific keys your DllRegisterServer call sets up. But once you know what those are, you can move them to a .pkgdef.

    The bug I mentioned just prevents the IDE from knowing about the older VC++ project template that allows you to create new VC++ based packages. It doesn't prevent native C++ packages from working. Many of the core Visual Studio services are actually implemented as native C++ packages.

    Sincerely,


    Ed Dore

    Wednesday, March 22, 2017 12:43 AM
    Moderator
  • Hello Ed,

    Based on discussion so far, it looks like that I should be able to add registry keys for Native and managed C++ packages in a single .pkgdef file. Since we support integration from VS2005 till VS2015 and plan to support VS2017 as well, I am assuming that VSIX deployment is not an option to deploy pkgdef files. What is the next best option ? regpkg cannot be used because we cannot expect it to be present on every client's machine. Moreover /root needs to be pre-populated with the registry hive location which would not be feasible as well.  

    Or as mentioned in several posts, should we use the VSIX deployment mechanism for pkgdef and drop support for VS2005 and VS2008 versions ? If yes, will a single vsix file will work for all versions of Visual Studio starting from VS2010 - VS2017 ?



    Vinita

    Thursday, March 23, 2017 2:45 PM
  • A single VSIX file cannot target VS 2010-2017, because VS 2010 uses manifest "version 1", that is accepted by VS 2012-2015 but not by VS 2017. On the other hand, VS 2017 only supports manifest "version 3", but it is compatible with "version 2" accepted by VS 2012-2015.

    So, keep you existing deployment mechanism for VS 2005-2010 and use a single .vsix for VS 2012-2017.

    See my post:

    It’s time to change the VSIX manifest of your extension to v3 for Visual Studio 2017 compatibility


    My portal and blog about VSX: <a href="http://www.visualstudioextensibility.com"> http://www.visualstudioextensibility.com</a> Twitter: https://twitter.com/VSExtensibility MZ-Tools productivity extension for Visual Studio: https://www.mztools.com

    Friday, March 24, 2017 9:28 AM
    Moderator
  • Hello Ed,

    We have been able to create a .pkgdef file, by adding the registry keys manually. However, we have concerns pertaining to hard coding of resource string IDs and GUID constants, as this is not a scale-able solution and high on maintenance. Does pkgdef allow placeholders which can be replaced either during compilation or runtime ? Please note that we are referring to custom placeholders and not the ones mentioned at https://msdn.microsoft.com/en-us/library/ee390882.aspx.


    Vinita

    Thursday, April 20, 2017 10:42 AM
  • If all you are doing is targeting multiple versions of VS, your resource strings and guids should not be changing, so I'm not sure why there would be concern here. The .PKGDEF placeholders are not extensible, meaning there is no facility that allows you to add additional placeholders.

    For native C++ packages, there is no way to automatically generate the .pkgdef file, so you pretty much have to hand craft it. Managed packages are a different story, because we can auto generate a .pkgdef during the build, thanks to various attributes that decorate the package class. That functionality simply isn't available in C++ land.

    Sincerely,


    Ed Dore

    Friday, April 21, 2017 2:24 AM
    Moderator
  • Hello Ed,

    Thanks for the information.  We have been able to register managed and unmanaged packages which write to HKLM via pkgdef. However, we have libraries wherein .rgs writes to HKCR hive, and trying to convert these into pkgdef have not been a success.  How do we register these libraries in VS2017 ?


    Vinita

    Monday, April 24, 2017 4:54 PM
  • Hi Vinita,

    You'll need to identify the registry keys registered by those embedded .RGS resources, and move them to your .pkgdef. If there's a particular .RGS file you're having problems with post the details to a new form post, and folks can make some suggestions.

    Back in the "old days", older C++ packages could be registered via regsvr32.exe, but those days are long gone. Chances are you may have some keys under HKLM or HKCR that just need to be moved to the VS hive.

    Sincerely,


    Ed Dore

    Thursday, April 27, 2017 2:40 AM
    Moderator