Development of a third registry provider

[Google Code Exporter]

A third kind of registry provider should be introduced, next to the 
virtual and transparent registry implementations.

This new provider must ease the manageability of the virtual registry,
by providing the following features:
- Block the retrieval of a handle for requests that match an underlying 
dynamic list of registry keys and values.
- Make specific keys transparent or not-transparent, overriding the 
default AccessMechanism
- Must have priority over the other registry implementations.
- Keep track of a hit count and perform a specified action when reached 
(eg removal of the block-list)
- Underlying lists must be completely dynamic
- ...


By introducing such a provider, the following could be fixed and/or 
improved:
- Fix support for managed targets
When starting a managed target a blacklist could be created with the keys 
and values needed by .NET to dynamically invoke a method. A maximum hit 
count can ensure the removal of these entries when the method invocation 
has completed.
- Provide means to manage the virtual registry
For example, currently installers are in some cases able to detect they 
have been installed already. System administrators could trick targetted 
installers by specifying a list of keys and values for which the error 
code FileNotFound must always be returned.

Original issue reported on code.google.com by [e-mail] on 1 Apr 2010 at 3:20

[Google Code Exporter]

In its first implementation the scope of this issue will be narrowed to 
introducing a 
registry key black list with hit count and full priority.
Letting users decide whether or not specific keys need to be transparent or not-
transparent currently seems to be completely useless. Therefore it's not 
justified to 
commit the major changes needed in the virtualization engine.

Original comment by [e-mail] on 4 Apr 2010 at 4:03

• Changed state: Started

[Google Code Exporter]

The described issues can't be fixed by using a third registry provider.

In stead an extra type of AccessMechanism should be added: 
AccessMechanism.Virtual
This value would specify that only the virtual registry must be used, and that 
the 
host's registry must never be accessed.
An example use case could be HKEY_LOCAL_MACHINE, which always uses 
TransparentRead, 
while in some cases HKEY_LOCAL_MACHINE\SOFTWARE\ should be completely virtual 
(at 
least while packaging an application)

In a later stage an Engine Rule Framework should be introduced. This rule 
framework 
should basically provide the ability to let the user configure specific 
AccessMechanism values for specific keys, key trees, or key values.

Original comment by [e-mail] on 30 Apr 2010 at 10:35

• Changed state: WontFix

[Google Code Exporter]

AccessMechanism.Virtual -> Issue 17
Engine Rules Framework  -> Issue 16

Original comment by [e-mail] on 9 May 2010 at 10:48