RE: Remote Win64 registry access from Win32 managed app ?
- From: jetan@xxxxxxxxxxxxxxxxxxxx ("Jeffrey Tan[MSFT]")
- Date: Wed, 18 Jun 2008 07:15:40 GMT
Hi Lance,
This blog article should talk about the .Net Framework2.0.
Based on my research, I find that both .Net Framework3.0 and 3.5 has
defined KEY_WOW64_64KEY flag in an internal static class
"System.ServiceModel.ComIntegration.SafeNativeMethods". It is defined and
used by some internal *private* methods such as
System.ServiceModel.ComIntegration.RegistryHandle.Get64bitHKCR().
Unfortunately, these methods are not exposed in .Net Framework3.0/3.5 as
public methods, so they still can not be used by end user code but
leveraged by .Net Framework internal code.
Can you tell me why you can not use p/invoke in your own application with
KEY_WOW64_64KEY flag? As you can see, the .Net Framework code also
p/invokes the Win32 RegOpenKeyEx+KEY_WOW64_64KEY to get the job done. So
there should no problem if you use p/invoke to accomplish the job. The only
problem I can think of is the .Net code access security since p/invoke
requires SecurityPermission.UnmanagedCode. So, is it true that your
application does not have SecurityPermission.UnmanagedCode permission?
Thanks.
Best regards,
Jeffrey Tan
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:
msdnmg@xxxxxxxxxxxxxx
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day 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 or complex
project analysis and dump analysis issues. 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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
.
- Prev by Date: Re: Relationship between versions of .Net Framework
- Next by Date: Re: Relationship between versions of .Net Framework
- Previous by thread: Error code 0x80070035 - The network path was not found
- Next by thread: Handling Unhandled Exception in DotNet
- Index(es):
Relevant Pages
|
