Click here to Skip to main content
15,888,351 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
I am porting some VB6 registry access code to C#.net 2010.
I have found the Microsoft.win32.registry class.
The problem is am trying to solve is in the VB code all of the Keys are defined as HEX values and the functions are pretty lengthy. they don't seem to match the methods I'm seeing on .NET Framework 4.0.

Can anyone provide me with a cross reference between these functions and do I still need to declare the HEX values for things like HKEY_CURRENT_USER or are these properties of the class?
thanks in advance..
Posted

I am not sure which functions you are specifically referring to, but all the registry access functions are in the Microsoft.Win32.RegistryKey class.

The Microsoft.Win32.Registry class exposes all the root keys such as HKEY_CURRENT_USER so that you can refer to them as Registry.CurrentUser (which will retrieve a read-only key for that root). Once you have the root that you want, all the rest of the functions are called from that key.

RegistryKey members[^]

Did I understand your question correctly?
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 4-Apr-11 20:41pm    
I think you understand it correctly. My 5 for your Answer. For OP, the best bet is certainly stop using Registry, please see my Answer.

Hey, thank you very much for your warm words you said in response to http://www.codeproject.com/Messages/3841469/A-big-thank-you-to-SAKryukov.aspx.
--SA
MacIntyre 5-Apr-11 11:08am    
Thanks.. Exactly what I was looking for..
Cheers..
First of all, it looks like you're missing something important in programming. There is no such thing as "Hex values" or "decimal values". There are values of different integer types and there are strings. Hex or decimal or binary can be different representation if integer values in the string forms. A binary string representation is not really binary in the sense that it uses one character ('0' or '1') per bit, and this character takes 1 or 2 bytes, depending on encoding.

You can access Windows Registry using the class Microsoft.Win32.Registry. I don't think anyone would be interested looking for correspondence between VB6 run-time and this class. And I don't think you even need it. Just read this and related topics: http://msdn.microsoft.com/en-us/library/microsoft.win32.registry.aspx[^].

Please understand: this class is not a part of standard library (part of .NET libraries are standardized by ECMA and ISO); also the use of Windows Registry is completely discouraged. Using the Registry by an application is really a bad idea. Moreover, if you use standard libraries only (and some non-standard ones, such as System.Windows.Forms) your code can work on many platforms, such as Mac, Linux and many more — via Mono (http://en.wikipedia.org/wiki/Mono_(software)[^]). If you use Registry — forget it! — your software is not really portable between different Windows system.

So, there is only one good way — stop using Registry. (Well, you already have my answer on using Registry anyway, so this is a step forward.) What to use instead? Well, one thing is Configuration, see http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx[^], another one — settings, see http://msdn.microsoft.com/en-us/library/aa730869(v=vs.80).aspx[^]. Most general advice on using and persisting (writeable) application-specific data is this: you need to use the method System.Environment.GetFolderPath(System.Environment.SpecialFolder) to get write path where you want to store your data. Most typically, you would use System.Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData). See System.Environment.SpecialFolder, http://msdn.microsoft.com/en-us/library/system.environment.specialfolder.aspx[^] for other folders, System.Environment.GetFolderPath, http://msdn.microsoft.com/en-us/library/14tx8hby.aspx[^] for more information.

—SA
 
Share this answer
 
v2
Comments
JOAT-MON 4-Apr-11 20:52pm    
5 - Good advice, a better way to handle this.

My pleasure...you earned it! :)
Sergey Alexandrovich Kryukov 4-Apr-11 21:05pm    
Thank you very much.
--SA
MacIntyre 5-Apr-11 11:12am    
Thanks. This is great advice. If I were making the decissions this would actually be the way I would implement the solution. But alas, it is not up to me. If I were a tool things would be different, but I am just being used as a hammer to pound out VB6 written in C#. It is awful.
thanks for your references, I will see if I can change their minds in the code walkthru.
Thanks again, Cheers..
Sergey Alexandrovich Kryukov 5-Apr-11 13:01pm    
Thank you.
I must say "Not up to me" is not the best approach, even if you're not the one who makes the decision. As a developer, your major and one of the most difficult skills is to oppose wrong solutions. If you have a good leader, she or he will appreciate that, if not... you know, if the wrong solution hits the company, you can easily be blamed anyway. Developers are supposed to speak up and discuss the assignments, not just doing wrong thing.

Besides, why would you appeal to me on this topic? You asked the Question, not anyone else, so I treat you as a decision-maker. Why should we address interpersonal problems in your company?

Please think about it.

By the way, how about formally accepting my Answer, if you think it deserves it?
Thank you.
--SA
MacIntyre 5-Apr-11 14:48pm    
Thanks for the followup.
We are really stuck with the registry solution for two reasons.
The First is the worst reason, "We've always done it that way."
The second is the real reason. We are actually integrating with a third party "Propritary Mumps" application. This propritary application in the real business world would have been TRASHED, 30 years ago, but this is healthcare. The application looks like your worst "DOS" application nightmere, all keystroke oriented. So we either hire an army of 'DataEntry" clerks or play this silly game. Back in the old days we called it ScreenScraping, identify places on the application screen for automatically entering data, thus creating a batch environment in real time. The target application uses the registry for knowing which hospital to process, hence we have to automate the hospital selection and update the registry before the the batch operation begins. We could rewrtie the entire operation using modern languages and databases for less money than it costs them to do what they do today. But, "We've always done it this way." I'm just a contractor delivering to goods they are willing to pay for.
Thanks for you input. Cheers..

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900