Compartilhar via

Weirdness in data after .REG file import, Pt 1

  • Artigo

Have you ever noticed that after an import of a .REG file that the values and keys don't map up to be the same as they were before the import? Yeah, this is a bug in our tools. There are actually two known bugs in our tools which cause issues when someone imports a registry file (.REG) which has any keys whose default value is not blank (which is the default behavior) or when there are spaces in the key names or Value Names.

The only two solutions thus far is to temporarily manually edit your .REG file, import the file into a SLD file, and then manually modify that file with Notepad to remove the temporary edits from the SLD file or to modify the keys in an odd way in Component Designer. The manual edit workaround is kind of involved and there is quite a bit that one must pay attention to while working around this issue so that the data isn't inadvertently corrupted.

Description of problem:

If I create two components, one of which is created from the import of the default .REG file (“Test_Fail”) and the other created using the workaround (“Test_Pass”) – the following is the resulting build log from Target Designer when building each component.

 Warning  1116: Building unreleased component: "Test_Fail [Version 1.0, R1]"
Warning  1006: Invalid registry data fixup: 
HKEY_LOCAL_MACHINE\ SOFTWARE\ Test\ Test_With_Default_Assigned
Building: "Test_Pass [Version 1.0, R1]"...
Warning  1116: Building unreleased component: "Test_Pass [Version 1.0, R1]"

 Here's the contents of a registry file (see link below) that would cause this error. 

 Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Test]

[HKEY_LOCAL_MACHINE\ SOFTWARE\Test\ Test_WithOut_Default_Assigned]

[HKEY_LOCAL_MACHINE\ SOFTWARE\Test\ Test_With_Default_Assigned]
@="This is *NOT* the default \"(value not set)\" value"

Translates to the following once it is inside of the registry

 HKLM\Software\Test
    \Test_WithOut_Default_Assigned

     \”(Default)” : REG_SZ : "(value not set)"

     \Test_With_Default_Assigned
    \”(Default)” : REG_SZ : "This is *NOT* the default "(value not set)" value"

Before I describe the workarounds I must stress a couple points of the process.

  • At each step – back up the original file before you bulk edit something – just in case.
  • Here is a reg file that reproduces the issue and here is a reg file that is "fixed". (rename each to .reg if you save them off to utilize them if you choose to do so) These registry keys show that this operation is *GENERALLY* safe; however, please always keep track of what has changed with a differencing application such as Beyond Compare from Scooter Software.

Workarounds:

Here is the first workaround. This method is better if you have a huge amount of registry keys which exhibit this behavior.

Step one is to modify your .REG file with some temporary edits so that all of these changes are traceable and revert-able. Open your .REG file and replace all instances of \@=” with “((BAD_DEFAULT_VALUE))=“. The quotes around the temporary value are needed to force the import process to create a value type instead of a key type for the registry resource.

The second step is to import the .REG file into Component Designer and save off the resulting SLD file. Turn around and copy the SLD file into another file to back up the SLD in case something bad happens. The third step is to open that SLD file in Notepad and replace all instances of ,"((BAD_DEFAULT_VALUE))" with nothing (or an empty box in the find/replace dialog). Be sure to include the initial comma in that action as that needs to be removed as well. This step fixes the registry key names since the import process will have copied the temporary value into the name for the appropriate registry resource.

The third step is to open the SLD file again and repeat the step immediately above but instead replace ((BAD_DEFAULT_VALUE)) with nothing. This time we’re actually replacing the @=” portion of the above registry data.

The final step is to verify the results on a couple items then save off the SLD file. Re-open the modified SLD file with Component Designer and verify that your registry keys are how they should be. They should not be malformed, contain the ((BAD_DEFAULT_VALUE)) string, or any other weirdness. If this checks out ok then you should be good to go.

Here is the second workaround. This method is better if you only have a couple of registry keys which exhibit this behavior.

Step one is to import your .REG file into a component using Component Designer. After you’ve completed that, scan your registry resources for any keys which you know whose default value is set and fix them using the following steps.(and as such – are apart of this bug)

After you locate a broken key, double click on the key in question to open the edit dialog that is shown above. Click on the “Key Only” checkbox *TWICE* . Your Key name and Value will differ; however, the Value name should be the same. What this does is it tells Component Designer that the item has changed and therefore allows you to click the OK button. After the OK button is clicked the correct data is written to your SLD (when you save it next) and the key will build properly as well as function properly inside of the OS. Below are two screenshots of my test component which are a before and after shots that show how the keys should look before and after the fix. These screenshots apply to both workaround methods.

From this screenshot:

To this screenshot:

The visual difference between the two screenshots is the fact that the middle key actually is a value type as opposed to a key type which then results in the icon in transitioning from the folder to the registry key REG_SZ icon.

..And that's it! Those are the workarounds for this bug. It should be noted that this bug is being investigated for inclusion into Feature Pack 1.

Update: changed title, was too confusing

- Nick