/build/static/layout/Breadcrumb_cap_w.png

Importing registry entries

Heya folks. Got an annoying problem with regards to importing registry keys.

We have created a few custom package meta data fields. For internal auditing we create a RegKey that writes application name, version number, etc...

When we import this registry into the package (Installation Expert -> Feature Details -> Registry, then click on Add -> import and add the .reg file it adds some extra characters to the fields. But only on our custom fields.

[HKEY_LOCAL_MACHINE\SOFTWARE\OURCOMPANY\[ProductName]_[ProductVersion]]
"iDate"="[Date]"
"IDir"="[PRIMARYFOLDER]"
"iTime"="[Time]"
"IType"="[iType]"
"IUser"="[%username]"
"Manufacturer"="[Manufacturer]"
"OS"="[OS]"
"PackageVersion"="[PackageVersion]"
"ProductName"="[ProductName]"
"ProductVersion"="[ProductVersion]"

We've had to add the double ] to the end of the actual key as on import it drops the last ].

An example of how one of our custom fields imports is as follows. (With the additioanl characters in red)

[\[]iType[\]]

Any clues, help or suggestions much appreciated.

0 Comments   [ + ] Show comments

Answers (9)

Posted by: Foleymon 14 years ago
Orange Senior Belt
0
I have a couple apps that gave me trouble importing reg keys. What I have done is execute the key file 'branding.reg' by calling regedit from the script.

Execute %WIN%\regedit.exe /S %REG_KEY_SOURCE%\BRANDING.REG
Posted by: jcarri06 14 years ago
Senior Purple Belt
0
Ninja,

Have you considered updating your Windows template msi with these values? Back up you "Windows Application.msi" file from you sharepoint, then update the msi with the registry items you want in all your MSI. This way, every time you create an MSI, they will already be there.

- J
Posted by: sk 14 years ago
Senior Yellow Belt
0
Be careful with importing keys like [PROPERTY1], because [ will be replaced by [\[], it is better to put it in the template as mentioned, or create a macro/script that places them in the msi (wsi if you use wise) called "standardize" for example.
Posted by: jmcfadyen 14 years ago
5th Degree Black Belt
0
don't ever do what Foleymon has suggested its a very bad idea.

Why people do these things I will never understand when you have a deployment solution that is designed to cater for such deployment as registry why call an external script to cater for it.

Additonal to that in locked down environments it pure fail.

If you need this quick and easy just use the automation objects to edit your installer directly. One assumes your using MSI in which case its pretty easy with some SQL update / insert commands.
Posted by: Tone 14 years ago
Second Degree Blue Belt
0
I would have thought the easiest way would be to add to template as already suggested.
Posted by: ninjamaster 14 years ago
Senior Yellow Belt
0
Key inserting whilst creating an MSI is not a problem. It's when customizing manufacturer's MSI's using a transform that is the problem.

I'll look at embedding some vb code to add teh registry keys.

:)
Posted by: jmcfadyen 14 years ago
5th Degree Black Belt
0
what packaging tool are you using ?

Wise has a good method for dealing with this. I won't go into if your using IS.
Posted by: anonymous_9363 14 years ago
Red Belt
0
Wise has a good method for dealing with thisDoes it? The templates are used for creating new MSIs, true, but remember the OP wants to have this information automatically included in transforms created via InstallTailor. Refer to Jim's other post http://itninja.com/question/gnu,-freeware-and-shareware-programs-to-cloning7789. I don't think Wise handles that, does it? If it does, do tell us how!
Posted by: jmcfadyen 14 years ago
5th Degree Black Belt
0
I use Wise Macro's all the time for doing just this.

Its quick and painless repeatable. Handles reference counting that templates can't.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ