locked
IVsBuildPropertyStorage vs MSBuild API RRS feed

  • Question

  • I have an MPF-based project system and have used both IVsBuildPropertyStorage and the MSBuild property API to access project properties on other projects within my solution.  I'm looking for thoughts on when you should prefer one over the other.

    Thanks in advance.


    Kirk Fertitta

    Tuesday, September 16, 2014 2:18 PM

Answers

  • If I'm a package developer, and I develop a new project type, it's only *recommended* for me to implement a build system that's integrated with the VS environment. Of course, it's better, but you can't presume anything.

    MsBuild being somewhat more recent (and external) than the pure VS interfaces, it would be my second choice. But at the same time, it can also be much easier to implement. So I would first try to query for integrated VS interfaces first, and try MsBuild after that if interfaces are not available.

    For your information, my company does write a specific project type package, and we support none of these systems, althought we do support IVsProjectCfg2 and IVsBuildableProjectCfg to integrate with the VS build menus.


    Simon Mourier

    Tuesday, September 16, 2014 8:50 PM

All replies

  • If I'm a package developer, and I develop a new project type, it's only *recommended* for me to implement a build system that's integrated with the VS environment. Of course, it's better, but you can't presume anything.

    MsBuild being somewhat more recent (and external) than the pure VS interfaces, it would be my second choice. But at the same time, it can also be much easier to implement. So I would first try to query for integrated VS interfaces first, and try MsBuild after that if interfaces are not available.

    For your information, my company does write a specific project type package, and we support none of these systems, althought we do support IVsProjectCfg2 and IVsBuildableProjectCfg to integrate with the VS build menus.


    Simon Mourier

    Tuesday, September 16, 2014 8:50 PM
  • Thanks Simon.  Agreed that the possibility for an external project system not supporting the VS interfaces is certainly something to guard against.  I suppose as well that if I have a chatty interface that might query lots of properties, then I would expect loading an MSBuild instance (perhaps once per property) just to get those properties might incur a noticeable overhead.  Unless your code is structured such that you have enough context to hold onto an instance (which is probably dangerous for somebody else's project system), then this "feels" like a drawback to MSBuild. 

    But, what about when I'm communicating between different project systems that I own (i.e. are part of my package and MPF-based).  Would you always choose to operate on the MSBuild project instance that MPF maintains, or would you still try to go through IVsBuildPropertyStorage (which is known to e implemented for our project systems)?  Perhaps it's a distinction without a difference...


    Kirk Fertitta

    Tuesday, September 16, 2014 9:04 PM
  • The thing with MsBuild is it's really easy to use *outside of VS*.

    Well... actually, that seems to have changed because since a year or so, MsBuild is now part of Visual Studio: http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx

    However, when you read over that post, it seems clear MsBuild is the way to go in your context for a minimum implementation. I probably would also implement IVsBuildPropertStorage on top of it (using MsBuild to actually store things). In our case, we don't implement IVsBuildPropertStorage ourselves, but we do rely on it for other 'foreign' packages (C#, VB.NET, etc.).

    PS: IMHO, MPF is a terrible piece of code (full of shortcuts or non-said tricks). But, ok, that's all we have :-)


    Simon Mourier

    Tuesday, September 16, 2014 9:20 PM
  • Hi Simon,

    Thanks again.  Yes, MPF certainly leaves a great deal to be desired.  To be clear, when I say "MPF", it is actually based on other projects like Python and F# and NodeJS that have employed it successfully with lots of customizations to work around its many shortcomings.  I say "MPF" so people know what the base code is.  Incredible that MS hasn't released something publicly better yet...

    Are you using a form of MPF or did you just start from scratch implementing the PIA interfaces?  Or is yours an unmanaged project system?  I did a couple without MPF years ago and we maintain those, but in recent years we've had to add several more project systems and our non-MPF ones were not general enough, so we had to resort to MPF.


    Kirk Fertitta

    Tuesday, September 16, 2014 9:29 PM