Vista Setup Project - Rights Issue

[Smurfman-MSDN]

Using Vista Ultimate x64 and Visual Studio 2008 SP1

I have a solution with a setup project in it - everything is configured for
x86

I have several registry keys created as part of the installer.
Two keys are created as REG_SZ

Process Begin
Process End

By default I assign 2 values to the keys in the Registry editor for the
Setup Project
Process Begin is assigned "#8:30:00 AM#
Process End is assigned "#4:55:00 PM#

When the installer runs, I receive an error telling me:
"Could not write value Process Begin to key \Software\MYCompany\MyApp.
Verify that you have sufficient access to that key, or contact your support
personnell."

I can continue...

I get the same thing again for Process End

I can continue

The program installs. And every registry key is created, even the captured
values during the install pages are stored. EXPECT the two in question.

I suspect that it has to do with the data I am trying to write to the key
#8:30:00 AM#

Any suggestions?
J

 

[Smurfman-MSDN]

Thanks for the links - however I do not believe this is the issue.

As mentioned, the installer project is creating about 23 values for various
uses.

Only 2 are not being created. The two mentioned.
I suspect that the issue is related to the default value I am assigning in
the editor of the project.

Specifically the leading # sign.

Thanks
J

 

[jacky kwok]

Thanks for the links - however I do not believe this is the issue.

As mentioned, the installer project is creating about 23 values for various
uses.

Only 2 are not being created. The two mentioned.
I suspect that the issue is related to the default value I am assigning in
the editor of the project.

Specifically the leading # sign.

Thanks
J

Yes, I also experenced the same problem. If use "#" in the registry key
string leading, the installer will always fail.

By using tool "Orca" to check an installer msi Registry table, I found
that leading "#" is used to indicate it is an integer key.
Hence, all the registry record with leading "#" will be considered as
Integer an so that it will fail if the value is not an integer.

 

[Jie Wang [MSFT]]

Hello Jeff,

Jacky is right (thanks for sharing, Jacky). And let me share some more
detailed information with you.

In Windows Installer, we must make sure that the characters following a #
in a registry value are numeric. In your case, the value you set in the
Setup Project should be something like "##8:30:00 AM#". Note the double #,
that means the following characters don't have to be numeric.

There are tools that can be used to validate your MSI file before sending
it to deployment. As Jacky mentioned, Orca is one of the tools and it is
free for download from Microsoft website.

In case you need it, you can find it (contained in Windows Installer SDK)
here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=6A35AC14-2626-4846-
BB51-DDCE49D6FFB6&displaylang=en

After installing the Windows SDK, you can find Orca.msi from the SDK's
Tools folder. Then you need to install orca.msi.

After installing orca.msi, you can find Orca in your start menu.

Then you can consider the following steps to validate your MSI file:

1. Open your own MSI file with Orca.
2. From Tools menu, choose Validate
3. In the Validation Output dialog, click the Go button.
4. Wait for the validation process to finish.

When the validation process is finished, you may see the following error
message:
ICE70 INFO ICE70 - Checks that the characters following a # in a registry
value are numeric
ICE70 INFO Created 07/14/1999. Last Modified 07/21/1999.
ICE70 ERROR The value '#8:30:00 AM#' is an invalid numeric value for
registry entry _XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. If you meant to use a
string, then the string value entry must be preceded by ## not #.

So, all we have to do is close Orca, back to Visual Studio, change the
value from #8:30:00 AM# to ##8:30:00 AM#, and recompile.

For more information on ICE70, you may want to read the following documents:
http://msdn.microsoft.com/en-us/library/aa369020(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa369206(VS.85).aspx

And for ICEs (Internal Consistency Evaluators), here is the link:
http://msdn.microsoft.com/en-us/library/aa369554(VS.85).aspx

Please kindly let us know if this works for you.

Regards,

Jie Wang ([email protected], remove 'online.')

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Smurfman-MSDN]

First I appoligize, I did reply but it appears that it never posted.

Thank you both jacky and Jie.

I did try the ## setting and this worked perfectly.
I did not get the Orca program but thank you for the link.

This does raise a couple of questions that perhaps you can answer.
1) Why did it work on XP?
2) If in the Registry builder - I am adding a STRING value per the context
menu of the compiler, why does it not know that I am entering a string and
not an integer?
3) If the Registry builder is a string value - why doesnt the compiler
accept this and build it accordingly for the installer package.
4) Do I need to keep the same logic when setting the string value
programatically - for example #8:00:00 AM# to be stored in a REG_SZ value -
using the My.Computer.Registry.SetValue function?

Thanks
J

Hello Jeff,

Jacky is right (thanks for sharing, Jacky). And let me share some more
detailed information with you.

In Windows Installer, we must make sure that the characters following a #
in a registry value are numeric. In your case, the value you set in the
Setup Project should be something like "##8:30:00 AM#". Note the double #,
that means the following characters don't have to be numeric.

There are tools that can be used to validate your MSI file before sending
it to deployment. As Jacky mentioned, Orca is one of the tools and it is
free for download from Microsoft website.

In case you need it, you can find it (contained in Windows Installer SDK)
here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=6A35AC14-2626-4846-
BB51-DDCE49D6FFB6&displaylang=en

After installing the Windows SDK, you can find Orca.msi from the SDK's
Tools folder. Then you need to install orca.msi.

After installing orca.msi, you can find Orca in your start menu.

Then you can consider the following steps to validate your MSI file:

1. Open your own MSI file with Orca.
2. From Tools menu, choose Validate
3. In the Validation Output dialog, click the Go button.
4. Wait for the validation process to finish.

When the validation process is finished, you may see the following error
message:
ICE70 INFO ICE70 - Checks that the characters following a # in a registry
value are numeric
ICE70 INFO Created 07/14/1999. Last Modified 07/21/1999.
ICE70 ERROR The value '#8:30:00 AM#' is an invalid numeric value for
registry entry _XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. If you meant to use a
string, then the string value entry must be preceded by ## not #.

So, all we have to do is close Orca, back to Visual Studio, change the
value from #8:30:00 AM# to ##8:30:00 AM#, and recompile.

For more information on ICE70, you may want to read the following documents:
http://msdn.microsoft.com/en-us/library/aa369020(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa369206(VS.85).aspx

And for ICEs (Internal Consistency Evaluators), here is the link:
http://msdn.microsoft.com/en-us/library/aa369554(VS.85).aspx

Please kindly let us know if this works for you.

Regards,

Jie Wang ([email protected], remove 'online.')

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jie Wang [MSFT]]

Hi Jeff,

Let me try to answer your questions:

1) Why did it work on XP?

No, it shouldn't. I did the same test on various platforms - XP / Vista /
7, each with different versions of Windows Installer - 3.01 on XP, 4.0 on
Vista and 5.0 on Windows 7, got consistent error message. Since I can't see
your setup project, I'm not sure why exactly it works for you on XP. If
you'd like to, you can send me a small sample so I can check it up.

2) If in the Registry builder - I am adding a STRING value per the context
menu of the compiler, why does it not know that I am entering a string and
not an integer?
3) If the Registry builder is a string value - why doesnt the compiler
accept this and build it accordingly for the installer package.

Let me combine the 2nd & 3rd questions' answer together: It does know what
type of data you're entering. The problem is how the MSI package stores
these data.

Let's study a simple sample:

Say we have three values to write to the registry: TestString, TestBinary,
TestDWORD. In Visual Studio, we create three corresponding keys, and enter
their values.
Please note that the TestDWORD will not accept "10AD", we'll have to enter
"0x10AD" - the hex form, and it will be transformed into dec from 4269
automatically.

Then we compile the setup project, use Orca (yeah we have to use it again
to see what exactly happened) to open the compiled MSI, find the Registry
section, we'll see how these keys are stored:

TestString 10AD
TestBinary #x10AD
TestDWORD #4269

So, it is clear now in MSI it uses prefix like #x & # to differentiate data
types. There is no way for Visual Studio to make MSI remeber the data type
except using these prefixes. The only problem within Visual Studio Setup
Project editor is, it doesn't check whether or not a String value we
entered starts with a # sign. It will be better to warn us at compile time
with information like "if you want to start your string with the # sign,
the string value entry must be preceded by ## not #.".

One more interesting test: if we create a *string* key in the editor, with
its value #123, after we installed the MSI, we'll find the value type is
DWORD instead of string!

If you're interested in the details of the prefix rules, this is the
document for it:
http://msdn.microsoft.com/en-us/library/aa371168.aspx

4) Do I need to keep the same logic when setting the string value
programatically - for example #8:00:00 AM# to be stored in a REG_SZ value -
using the My.Computer.Registry.SetValue function?

No. As we said, this is the MSI rule, which doesn't apply to VB programming.

Hope this answered your questions clearly. But again, if you have more
questions or concerns, don't hesitate to post here.

Regards,

Jie Wang ([email protected], remove 'online.')

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Smurfman-MSDN]

Jie,
Thanks for the great notes.

I am willing to bet that while I thought it worked on XP, the keys were not
in the original install MSI that I created. And we manually created after
the fact for testing, that is the only thing I can think of.

This raises two other questions - but I will post one as a new thread.

Related to the whole String, Binary or DWORD.

How would I store a REG_MULTI_SZ value in the Registry Editor for the Setup
Project - I don't see that as an option.

I did however notice that if I write a a REG_MULTI_SZ it does get converted
in the registry.

Thanks again for all of the great info - I have learned a lot on this topic.

J

Hi Jeff,

Let me try to answer your questions:

1) Why did it work on XP?

No, it shouldn't. I did the same test on various platforms - XP / Vista /
7, each with different versions of Windows Installer - 3.01 on XP, 4.0 on
Vista and 5.0 on Windows 7, got consistent error message. Since I can't see
your setup project, I'm not sure why exactly it works for you on XP. If
you'd like to, you can send me a small sample so I can check it up.

2) If in the Registry builder - I am adding a STRING value per the context
menu of the compiler, why does it not know that I am entering a string and
not an integer?
3) If the Registry builder is a string value - why doesnt the compiler
accept this and build it accordingly for the installer package.

Let me combine the 2nd & 3rd questions' answer together: It does know what
type of data you're entering. The problem is how the MSI package stores
these data.

Let's study a simple sample:

Say we have three values to write to the registry: TestString, TestBinary,
TestDWORD. In Visual Studio, we create three corresponding keys, and enter
their values.
Please note that the TestDWORD will not accept "10AD", we'll have to enter
"0x10AD" - the hex form, and it will be transformed into dec from 4269
automatically.

Then we compile the setup project, use Orca (yeah we have to use it again
to see what exactly happened) to open the compiled MSI, find the Registry
section, we'll see how these keys are stored:

TestString 10AD
TestBinary #x10AD
TestDWORD #4269

So, it is clear now in MSI it uses prefix like #x & # to differentiate data
types. There is no way for Visual Studio to make MSI remeber the data type
except using these prefixes. The only problem within Visual Studio Setup
Project editor is, it doesn't check whether or not a String value we
entered starts with a # sign. It will be better to warn us at compile time
with information like "if you want to start your string with the # sign,
the string value entry must be preceded by ## not #.".

One more interesting test: if we create a *string* key in the editor, with
its value #123, after we installed the MSI, we'll find the value type is
DWORD instead of string!

If you're interested in the details of the prefix rules, this is the
document for it:
http://msdn.microsoft.com/en-us/library/aa371168.aspx

4) Do I need to keep the same logic when setting the string value
programatically - for example #8:00:00 AM# to be stored in a REG_SZ value -
using the My.Computer.Registry.SetValue function?

No. As we said, this is the MSI rule, which doesn't apply to VB programming.

Hope this answered your questions clearly. But again, if you have more
questions or concerns, don't hesitate to post here.

Regards,

Jie Wang ([email protected], remove 'online.')

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Smurfman-MSDN]

Jie

Nevermind my last post - I found the answer in that link you gave me with
the [~] being a seperator for the values.

This will work great.

You can close this item.

Thanks a ton!
J

As a sidebar - I am getting a ton of Service Unavailable these last 2-3 days
when trying to update posts or look at other replies from MS people. Thought
I would let you know.

Thanks again.
J

Hi Jeff,

Let me try to answer your questions:

1) Why did it work on XP?

No, it shouldn't. I did the same test on various platforms - XP / Vista /
7, each with different versions of Windows Installer - 3.01 on XP, 4.0 on
Vista and 5.0 on Windows 7, got consistent error message. Since I can't see
your setup project, I'm not sure why exactly it works for you on XP. If
you'd like to, you can send me a small sample so I can check it up.

2) If in the Registry builder - I am adding a STRING value per the context
menu of the compiler, why does it not know that I am entering a string and
not an integer?
3) If the Registry builder is a string value - why doesnt the compiler
accept this and build it accordingly for the installer package.

Let me combine the 2nd & 3rd questions' answer together: It does know what
type of data you're entering. The problem is how the MSI package stores
these data.

Let's study a simple sample:

Say we have three values to write to the registry: TestString, TestBinary,
TestDWORD. In Visual Studio, we create three corresponding keys, and enter
their values.
Please note that the TestDWORD will not accept "10AD", we'll have to enter
"0x10AD" - the hex form, and it will be transformed into dec from 4269
automatically.

Then we compile the setup project, use Orca (yeah we have to use it again
to see what exactly happened) to open the compiled MSI, find the Registry
section, we'll see how these keys are stored:

TestString 10AD
TestBinary #x10AD
TestDWORD #4269

So, it is clear now in MSI it uses prefix like #x & # to differentiate data
types. There is no way for Visual Studio to make MSI remeber the data type
except using these prefixes. The only problem within Visual Studio Setup
Project editor is, it doesn't check whether or not a String value we
entered starts with a # sign. It will be better to warn us at compile time
with information like "if you want to start your string with the # sign,
the string value entry must be preceded by ## not #.".

One more interesting test: if we create a *string* key in the editor, with
its value #123, after we installed the MSI, we'll find the value type is
DWORD instead of string!

If you're interested in the details of the prefix rules, this is the
document for it:
http://msdn.microsoft.com/en-us/library/aa371168.aspx

4) Do I need to keep the same logic when setting the string value
programatically - for example #8:00:00 AM# to be stored in a REG_SZ value -
using the My.Computer.Registry.SetValue function?

No. As we said, this is the MSI rule, which doesn't apply to VB programming.

Hope this answered your questions clearly. But again, if you have more
questions or concerns, don't hesitate to post here.

Regards,

Jie Wang ([email protected], remove 'online.')

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jie Wang [MSFT]]

Regarding the Service Unavailable problem, I have reported it to
appropriate people and their will take a look.

If you're still having the problem, just email me or the msdnmg@msft dot
com for assistance.

Thanks,

Jie Wang ([email protected], remove 'online.')

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.