SVS Dependency Activator
If you have one layer that relies on another layer being active in order to function correctly this utility will activate the required layers. An example would be to make sure the data layer for a specific file type is active before the application layer will activate.
If dependency is set as critical, and the required layer cannot be activated, the dependant layer will be automatically deactivated.
This project has been on my to do list for nearly a year now. Feels good to finally build it and share it with the world. I hope you all like it.
You'll probably want to check out the SVS Dependency Setter too. It makes setting registry keys a breeze.
| License: | AJSL By clicking the download link below, you agree to the terms and conditions in the Altiris Juice Software License |
| Support: | User-contributed tools on the Juice are not supported by Altiris Technical Support. If you have questions about a tool, please communicate directly with the author by visiting their profile page and clicking the 'contact' tab. |
If you have any suggestions for improvement, please don't hesitate to post a comment, anything good will be worked into the next version.
| Attachment | Size |
|---|---|
| SVSDA1.0.1.zip | 289.48 KB |
- Login or register to post comments
- 3341 reads
- Printer-friendly version














Great stuff to work with.
Hi Jesse,
Great stuff to work with.
I guess right now there is no possibility for storing the dependency information within the layer itself, so it could be part of the layer export process?
Implementing it in SVS solution would be fun too.
Anyway, thx for the tool..
Jan
VSP Metadata
The VSP management metadata is located under the Magic Number key for the read-only sublayer in HKLM\System\Altiris\FSL. Whatever is there goes with the VSP when it is exported to an archive or published to a server ("publish," like "subscribe," is a new 2.1 feature that we'll explain when Beta 2 ships).
You can add anything you need to there. In fact, that's probably exactly where we'll put the dependency metadata from Wise Package Studio in a future release. So far, most customers and developers adding custom metadata are creating a new unique subkey for it, and I think that would make sense. We probably should doc that as design guidance in the SVS SDK.
Exactly the Reason
Knowing that everything under the magic # keys is included in the export is exactly the reason I wrote the program to read the keys from this location.
It was part of my design specs that this information be portable with the layer.
Layer Groups
I thought of another use for this. If you have a group of layers you want to activate together, create an empty layer named whatever you want the group to be called. Then, on this layer, create dependencies for all the layers you want in the group.
The effect; activating the "group" layer, will activate all layers in that group.
OnPostActivate vs. OnPreActivate
Dear Wm Jesse Foster,
Thank you for this feature.
I have some questions, mostly because I would like to understand why you designed it the way it is, and if I understand the basiscs of SVS.
- I wonder why you used OnPostActivate to start SVSDA? I could use OnPreActivate, couldn't I?
- What is the advantage to create a "Depend" key, over using the SVSCMD directly in the OnPost/PreActivate? I guess, because it would require a script if there are more then one dependency.
And to have a "critical" option the script would need to check the properties of the layer after activation, which would make the script quite long. since it would need to parse the output of SVSCMD. Did I miss something?
Ciao
toralf
OnPostActivate vs. OnPreActivate
If I had used OnPreActivate, there is no way to stop the layer from activating in case of a critical dependancy failure. Therefore, I used OnPostActivate so I could deactivate the layer if this happens. The layer has to be active before the program calls the deactivate function else it will not work.
Update Layer
Dear Wm Jesse Foster,
Thank you for the answer. It makes perfect sense.
I must admit, I haven't tried it yet. But I wonder if this dependency settings can also be used to update the master layer? Or rephrased: Can a layer that depends critically on other layers be updated?
Many thanks in advance
toralf
Not sure what you mean
There is no reason I can think of why you wouldn't be able to do an update existing layer. Nothing else touches the values this tool uses.
Sorry, another try
I'm very sorry for not being clear enough.
What I know from the documentation is that a layer can only be updated when no layer is active. The layer being updated gets activated during update. Right?
But now the to be updated layer activates other layers, thus more then one layer is active. Is this allowed for the update capture process?
Are the layers activated before the capture process begins? There might be a lag due to the OnPostActivation.
Sorry, if these questions are simple or trivial, but I would like to get this straight in my head. Thanks.
Good Point
That's a very valid question. That is something that I neglected to test. I cannot promise a quick turn-around but I will check that and try to figure out a way around it if it is a problem.
Thanks for confirming
Thanks for the reply, I don't feel stupid anymore. Take your time, the question is not pressing, and other users are informed now to be cautious.
Possible work-arounds
I haven't verified yet that this situation will cause issues, but if you find that it does, there are a couple possible work-arounds.
- Use the SVS Dependency setter (http://juice.altiris.com/node/890) to remove the critical dependencies before updating the layer. After updating the layer, re-add the dependencies.
- Go to HKLM\System\Altiris\FSL\layer# and rename the Depend key, update the layer then change the name back to Depend.
SVSDA Unhandled Exception
Hello Jesse,
Following your PDF for setting dependencies in SVS, I get the following error after activating my dependent layer:
Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object.
at SVSDepend.Class1.Main(String[] args)
I have verified this problem to persist across multiple .vsa files I have on my system. Any and all help is much appreciated.
Regards,