.NET and .INF files

[Vish]

I am planning to write a .NET WinForms application to Read/Modify .ini
files. Is there any .NET API / Schema for the same?

Thanks in advance.

-V.

 

[Lau Lei Cheong]

Using INI files to store value is obsolute. Consider storing values on
HKCU/HKLM registry keys instead.

For read/writing INI files, you can use these APIs:
[DllImport("kernel32.dll", EntryPoint="GetProfileString")]
private static extern int GetProfileString (string lpAppName, string
lpKeyName, string lpDefault, string lpReturnedString, int nSize);

[DllImport("kernel32.dll", EntryPoint="WriteProfileString")]
private static extern int WriteProfileString (string lpszSection, string
lpszKeyName, string lpszString);

 

[Vish]

Thanks for your reply, Lau.
I was wondering if I could do this using C#.

Thanks again.

-Vish.

-V.

 

[Richard Grimes [MVP]]

Using INI files to store value is obsolute. Consider storing values on
HKCU/HKLM registry keys instead.

Why?

Microsoft says that you should use a config file (ie a text file in the
application's folder) in preference to a registry key. Guess what an ini
file is? It is a text file in the application's folder!

There are distinct reasons *not* to use the registry. The most important
is that it kills xcopy deployment (how do you extract the values in the
registry from one machine and put them into the registry of another with
xcopy?). If you want xcopy deployment *do not* use the registry. Also
the registry tends to get bloated. If an application does not clean up
after itself it will leave values in the registry after it is
uninstalled and this bloating will eventually have an effect on the
performance of windows.

There *are* reasons why you should use the registry: it is a multiuser
database, so multiple threads can access the registry at the same time.
This is (usually) not the case with a file because a thread will lock
the file and prevent access to other threads. The registry is also
accessible via RPC, so a remote machine can change it. If you want to
have these enefits then you should use the registry. Otherwise, the
xcopy argument means that you should not use it.

That then leaves the question of whether you should use a config file
(XML) or an ini file. XML files are structured and so you can put richer
information in them. Personally I would not use the configuration file
API because in v1.1 this API only give you read-only access. If you want
to write data then use the XML serialization classes (XmlSerializer).
The xsd.exe tool is emmensly useful in generating code to do this.

Richard

 

[Michael D. Ober]

Why?

Microsoft says that you should use a config file (ie a text file in the
application's folder) in preference to a registry key. Guess what an ini
file is? It is a text file in the application's folder!

And before that MS said to use the registry and before that they said to use
INI files. What's next?

There are distinct reasons *not* to use the registry. The most important
is that it kills xcopy deployment (how do you extract the values in the
registry from one machine and put them into the registry of another with
xcopy?). If you want xcopy deployment *do not* use the registry. Also
the registry tends to get bloated. If an application does not clean up
after itself it will leave values in the registry after it is
uninstalled and this bloating will eventually have an effect on the
performance of windows.

I've been using XCopy deployment for VB 6 apps for several years. I use an
MSI file only when an application uses a control not already deployed and
then I initially deploy it via GPO, then updates are deployed via XCopy.

There *are* reasons why you should use the registry: it is a multiuser
database, so multiple threads can access the registry at the same time.
This is (usually) not the case with a file because a thread will lock
the file and prevent access to other threads. The registry is also
accessible via RPC, so a remote machine can change it. If you want to
have these enefits then you should use the registry. Otherwise, the
xcopy argument means that you should not use it.

Last time I checked (i.e. yesterday), I could open a file for multi-user
access, even across a network. So these two arguments against using a file
for configuration are null and void. Most config file access is read only,
so locking isn't usually an issue.

That then leaves the question of whether you should use a config file
(XML) or an ini file. XML files are structured and so you can put richer
information in them. Personally I would not use the configuration file
API because in v1.1 this API only give you read-only access. If you want
to write data then use the XML serialization classes (XmlSerializer).
The xsd.exe tool is emmensly useful in generating code to do this.

Because of the structured nature of XML files, they are royal pain to
update - you must update the entire file at a time. Windows has built in
API calls to create, maintain, and read INI files. Unless you must have
highly structured data in your config file, stick with ini files. For
highly structured configuration information, you should rethink your design.

Richard

Mike Ober.