Developer Center Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Avoiding 'vip hell' with VIPM packages

So other than David Staab, David L, and myself (also David--it's a conspiracy!) I haven't seen comments from others on this thread recognizing the potential for problems when package developers do not allow sxs installations.  That concerns me a bit.  Maybe I haven't communicated the problem well enough, maybe I'm missing out on an existing solution everyone else is aware of, or maybe nobody cares how I go about enabling sxs installation for LapDog.  I can't tell...

Do others see the need for some sort of solution allowing sxs installs?  Are there other solutions besides changing the package name, namespace, and install point that can be implemented quickly?  Are there alternative naming schemes that do a better job of communicating the relationships between packages in a package line?  Or should I just get off my soapbox and STFU? 

------------------------

David_L wrote:

I wanted to clarify something about the "official" stance of SxS on the LVTN.  I didn't mean to imply that any developer should or should not use SxS.  I can fully understand (and my assumptions are confirmed after this discussion thread) that both methods are very important in different situations.  The important thing in terms of the LabVIEW Tools Network is that whichever route you do choose it is easy to understand for the average user.

Thanks for the clarification David. That is very helpful. By the way, did you find any information on the toolkit version mutation api AQ suggested?

------------------------

Michael, if you still have questions about my points we can continue discussing it here or on the phone.  Either way works for me.

0 Kudos
Message 31 of 71
(2,011 Views)

Daklu, I don't use LapDog, but I do have internal reusable components that depend on VIPs that are about to be deprecated. I just previewed the next version of one of them (published by a group at NI, no less), and it doesn't properly namespace its typedefs across versions or provide mutation code. That means that installing the new package and opening up my component that depends on it resulted in all kinds of cross-linking issues and "missing VI" errors. So I absolutely see this as a real problem that needs a recommended solution.

Additionally, after spending an hour to review the changes made in this new dependency, I realized that I have no incentive to upgrade my dependent component because the changes (1) don't add any of the features I had to implement myself and (2) don't improve any of the quirks I had to work around in the older version. So now I have the conundrum of either (A) remaining dependent on the older package and suffering version conflicts when I put my component into any project that uses the newer one, or (B) spending a lot of nights and weekends to refactor my component and test it with the new dependency. Designing for SxS installation would fix my problems without doubt.

I don't mean to help start a political movement with this, but I do commiserate on the importance of the issue and the concern that nobody may care.

0 Kudos
Message 32 of 71
(2,011 Views)

Daklu wrote:

So other than David Staab, David L, and myself (also David--it's a conspiracy!) I haven't seen comments from others on this thread recognizing the potential for problems when package developers do not allow sxs installations.  That concerns me a bit.  Maybe I haven't communicated the problem well enough, maybe I'm missing out on an existing solution everyone else is aware of, or maybe nobody cares how I go about enabling sxs installation for LapDog.  I can't tell...

As I previously indicated, yes, I have the same concerns as you, and no, my name isn't David.





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 33 of 71
(2,011 Views)

Daklu wrote:

So other than David Staab, David L, and myself (also David--it's a conspiracy!)...

I'd like to just chime in to say that this is a concern.  And just to add to the conspiracy, my brother's name is David (does that count?).  I've been developing my own reuse library and I would like to design it with these issues in mind.  I don't really have a solution since I have yet to run into the problem myself.  But at least you opened my eyes to the future issues I will likely run into.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 34 of 71
(2,011 Views)

Thanks for the clarification David. That is very helpful. By the way, did you find any information on the toolkit version mutation api AQ suggested?

I briefly looked into the Mutation API.  It has some promise, but it will require some work to clean it up and make it safe for public consumption (similar to how we got scripting many years back and more recently Project Providers).  It's on our team's radar to continue investigation, but I can't promise any timeline.

0 Kudos
Message 35 of 71
(2,011 Views)

Daklu,

My name is not David and I appreciate the value of SxS installations in LabVIEW.  I think you have communicated both the problems and the solution well.

I am encouraged with the course of the conversation, which started with what looked to me like preciously little support for SxS, and progressed to discussion about best practices.  We have a lot of collective experience with "backward-compatible" upgrades of LabVIEW IP, and significantly less experience with SxS, which makes this discussion hard.

I am not aware of anything that prevents SxS installation in LabVIEW.  I would expect VIPM to work well if the different versions for SxS installation are entirely separate in every way (in which case both LabVIEW and VIPM will be left unaware of the relationship between packages previously described as belonging to a package line).

I am interested in exploring is SxS installations where a package is formally never revised.  For example, let's say that we have IP product called Foo 1.0.  If we elect to create a bug fix for Foo 1.0, it may be called Foo 1.1, so that Foo 1.0 and Foo 1.1 can coexist in SxS manner.  As a user of Foo 1.0, I may like it better than the "improved" Foo 1.1 because I invested time into verifying that Foo 1.0 works within my stack, and I may not be able to verify that Foo 1.1 works as well.  People make mistakes, so practical problem is that Foo 1.1 may have new bugs, and I may like old bugs from Foo 1.0 better. 

If the only difference between Foo 1.0 and Foo 1.1 is a behavioral change without any parameter changes to the VIs, and I like behavioral change, upgrade to the new version is conceptually simple-I would have to replace all elements from Foo 1.0 with corresponding elements from Foo 1.1.  I acknowledge that the time it takes to perform this conceptually simple change may depend on the number of places that reference VIs, typedefs, and other elements from Foo 1.0, but I see that as a separate problem.

What do you think about this:  SxS where we never revisit a version once it is shipped?

Kosta
0 Kudos
Message 36 of 71
(2,011 Views)
Chris wrote:

As I previously indicated, yes, I have the same concerns as you, and no, my name isn't David.

Sorry Chris.  In your post you mentioned a workaround so it wasn't clear to me that you thought it was a problem that needed to be addressed, and I didn't want to put words in your mouth.  (Same goes for several other posters--the messages kind of imply the problem needs to be solved, but don't specifically acknowledge it.  I'm not ignoring you but don't want to attribute undeclared meaning to what you're saying either.)

Kosta wrote:

What do you think about this:  SxS where we never revisit a version once it is shipped?

In principle I think that is a good direction to go, though there will certainly be complaints from users about the amount of hard drive space all the different versions take.  If you google "sxs folder size" you'll find lots of posts from people blasting MS for doing essentially the same thing, even though there are not a lot of alternative solutions.  (And even though Windows Explorer reports WinSxS using much more space than it really does.)

As a practical matter, I'm concerned the lack of existing LV infrastructure support will result in a very negative experience for the end user if we pursue that option too soon.  As you pointed out, switching versions takes a lot of effort, and I'm guessing most users would be fine with automatically upgrading all their Foo 1.0 code to Foo 1.1.  They will not be happy if they have to search and replace to receive every simple bug fix.  I've thought about creating scripts to automatically search and replace user code when the apis are compatible, but that is still a cumbersome solution.  Someone upgrading from Foo 1.0.3 to Foo 1.0.19 will have to install all 16 intermediate versions and run their upgrade scripts in order. 

(Edit:  Hmm... maybe it would be possible to write mutation scripts recursively so the search and replace parameters are mutated through all 16 versions but the actual search and replace operation is only done once.  That would eliminate having to install all the intermediate packages as long as the mutation code contained the entire history.)

The trick is making the upgrade (and downgrade) code replacement automatic for most people, but optional in those cases where a specific user application shouldn't automatically upgrade to the new package version.  Microsoft uses manifests to specify which versions of dependent components should be used by the application.  When the application starts, the OS reads the manifest to find the dependencies that need to be loaded.  By default the most recent version will be used, but users can edit the manifest file (it's in xml) and specify a single version or range of versions to use on a case by case basis.  There are lots of details once you dig into it, and it's not super easy to figure out if you've never had to deal with it, but it does seem to offer a decent compromise between ease-of-use for the common case while still allowing the flexibility to address exceptional circumstances.  (And as Jim alluded to early in the thread, it's very easy to change relink an application to a different version of the dependent assembly.)

(Edit:  WinSxS and the Global Assembly Cache are conceptually the same, with WinSxS used for native code and the GAC used for .Net assemblies.  From what I understand the implementation details are different.  I'm more familiar with the details on how the GAC works than WinSxS, so the brief explanation above refers to that.)

There's nothing (that I'm aware of) even remotely similar to the GAC currently in Labview, and I expect implementing similar functionality in LV dev environment would be quite time consuming.  On the positive side, this is primarily a dev environment issue rather than a run time issue, so maybe that would simplify things somewhat.  (Edit:  On second thought... maybe not.  Come to think of it I don't think the GAC allows multiple versions of the same assembly to be loaded into memory at the same time.  I don't know about WinSxS.)  Personally I'd rather wait a couple years for a good native solution than get an insufficient solution sooner.  If NI has ever thought about getting Brian Tyler back in the fold, this would be the project to get him for.

So yes, never overwriting a package version does give end users the most flexibility.  If that's the direction NI wanted to go from here on out I could get on board with it, but there's going to be a lot of pain in the short term while the tools and infrastructure catch up with the decision.  Also, it does make a lot of VIPM's current package replacement behavior obsolete.  Hopefully Michael won't want to shoot me you for bringing up the idea. 

All that being said, you mentioned you see changing package versions "as a separate problem."  Do you have something else in mind for simplifying the process of changing which package version a project uses?

-Dave

------------------

For those who responded to my question about the importance of sxs installations, I hereby bestow upon you the title of "David."  May you forever wear it with honor:

David Chris,

David Crossrulz,

David Kosta,

and of course,

David David

0 Kudos
Message 37 of 71
(2,011 Views)

DavidStaab wrote:

So now I have the conundrum of either (A) remaining dependent on the older package and suffering version conflicts when I put my component into any project that uses the newer one, or (B) spending a lot of nights and weekends to refactor my component and test it with the new dependency. Designing for SxS installation would fix my problems without doubt.

There is another option if the packages your component depends on are entirely internal to your component.  You can load your component source code with the previous package version installed, then do a "Save As..." on the package's source code, select "Substitue copy for original," and resave all the package's source code as a private library to your component.  It's easier to do if the package's source code is all in a single library.  You can do the same thing somewhat automatically if you build your component in a package and distribute it to yourself before you use it.

On the other hand, if your component exposes any part of the package externally, then this doesn't work.

0 Kudos
Message 38 of 71
(2,011 Views)

Good point, but:

  1. The typedefs from the dependency trickle up to my componenet's interfaces, and some of those typedefs changed while keeping their names.
  2. Lugging around a duplicate of the dependency inside my component bloats code. It's not often a big deal when working with LV's tiny (on disk) binary format, but it's the principle of the thing!

Really, as you said, #1 is what's really going to prevent that from working.

0 Kudos
Message 39 of 71
(2,011 Views)

DavidStaab wrote:

  1. ...
  2. Lugging around a duplicate of the dependency inside my component bloats code. It's not often a big deal when working with LV's tiny (on disk) binary format, but it's the principle of the thing!

Unless you want to work with mutation histories, I can't see any other way (unless, of course, you don't want to support SxS )





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 40 of 71
(2,011 Views)