Rob Ainscough

I have a class that I've created using .NET 2.0 framework that reads/writes to the classic INI files -- it uses Declare Ansi Function GetPrivateProfileString...Kernerl32.dll...approach.

Two questions:

1. Does .NET 3.0 or .NET 3.5 Beta 2 have any assemblies for doing classic INI read/writes

2. Where can I get a assembly/namespace road map for .NET 3.0 and .NET 3.5 Beta 2 -- a diagram would be nice

Thanks, Rob.



Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

Feng Chen - MSFT

Hi Rob,

As far as I know, .NET 3.0 or .NET 3.5 Beta 2 have no assemblies for doing classic INI read/writes. The recommended way of storing settings is application settings.

And there are several references about .net 3.0 and .net 3.5 namespaces:

.NET Framework 3.0 Class Library

.NET Framework 3.0

.NET Framework Class Library (WinFX) ĘC about .net 3.5.

Hope this helps!

Thanks!






Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

Rob Ainscough

I need the classic INI support so that my .NET 3.5 WPF app can read/write to existing legacy apps. Sorta surprised this isn't included in any of the .NET assemblies (from 1.0 to 3.5 Beta 2) Surely people communicate with legacy apps that are using INI files Can't believe I'm the only one Am I

Rob.





Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

ahmedilyas

Xml files are a replacement for ini files. Therefore since .NET is "new" and is the new generation, old things like ini files are not supported but only by Win32 API.

you could still use the Win32API Classes (P/Invoke) but there won't be any classes in .NET to do what you are asking since Xml is the new format for "application settings" and more.






Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

Rob Ainscough

Don't follow your logic at all Access databases are "old" but OLEDB is supported in the "new" .NET and I have no troubles working with data contained in Access97 databases.

INI files were a commonly used and in some cases are still being used as the performance of reading an INI file is considerably faster than reading XML files due to the verbose nature of XML specification. To assume that legacy applications and the"new" way of doing things will immediately go away or be discarded seems a little overly optimistic.

As stated I have a routine using the Win32 API, but as you know that has implications in WinXP 32/64 flavors in addtion to Vista x32/64 flavors and is technically "unmanaged" code. I want to avoid this and expected support for INI files in .NET whether it is the "preferred" way or not.





Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

ahmedilyas

Sure. I was only referring to ini files. Databases will always be there - but application settings are a replacement for ini files, as are xml too. ini files can be read using a StreamReader for example, since its a "string" based file. I understand what you mean though :-)

Perhaps contact wishlist [at] Microsoft [dot] com and pitch in the suggestion however doubt they would implement something that has a replacement for.






Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

GuyWithDogs

Could you use Nini at http://nini.sourceforge.net/ I'm looking at it for a new project where I'm getting my feet wet

It claims:

Features





Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

Dean Harding

If every legacy Win32 function was reimplemented in .NET there'd be no way for us to "move on" as it were... if you really must read/write .ini files, then you can use P/Invoke. Added classes for that to the BCL would mean that reading/writing .ini files would have to be "supported" for all time now until forever.

By the way, there are no restrictions on using P/Invoke on Vista or 64-bit windows. The code should work unchanged in both environments.





Re: .NET Base Class Library .NET 3.0 or .NET 3.5 Beta 2 INI reader/writer?

Rob Ainscough

Since I can't magically make these legacy applications go away, I have to support the INI files -- really is no choice. Maybe Microsoft hoped INI would go away, but the reality is they still exist and are still used regularly. This is one of the "legacy" items that should NOT have been dropped in the framework.

Besides that, my VS 2008 Beta 2 projects require .NET 3.5 Beta 2, .NET 3.0, and .NET 2.0 all to be installed soooo...adding INI support to .NET framework really isn't some major deal. Of course this begs the question how is having 3 version of .NET framework better than just updating MSFC of the old way...seems to me Microsoft have just shifted the burden of compatibility over to the developer and/or the End User.

I didn't know Kernel32.dll existed in Vista 64 nor in WinXP 64 But come to think of it -- ye old compatibility mode setting...hmmm...ok, I'll stick with the old way and just run some Vista 64 testing.

Rob.