[.NET] Custom config sections

[whoami]

Ik ben een .NET applicatie die ik in .NET 1.1 geschreven heb, aan het porten naar .NET 2.0.

In die 1.1 applicatie heb ik een app.config file, die een custom configSection bevat.
Die app.config ziet er dus bv zo uit:

code:

<configuration>
    <configSections>
          <section name="test" type="System.Configuration.NameValueSectionHandler"/>
    </configSections>
    <test>
          <add key="bliep" value="melp"/>
    </test>
</configuration>

Als ik die code gewoon overneem in een .NET 2..0 app, dan krijg ik een foutmelding:

could not find schema information for the element 'test'

Wat is hier aan de hand ?

[Gert]

<test /> komt buiten <configSections />

[whoami]

Gert schreef op zaterdag 18 februari 2006 @ 00:13:
komt buiten

Eh, ja... da's zo.
configSections beschrijven de config-sections die er zijn. De config-section zelf komt daar neit in, die komt er buiten.

[H!GHGuY]

als je op deze link kijkt zie je (spaans wel) hoe het wel moet

http://blogs.ugidotnet.org/Markino

er staan wel wat links die waarschijnlijk engelse tekst produceren + code die het ook wel duidelijk moet maken.

[whoami]

Nou, ik ga niet eerst spaans leren ofzo hoor.

Die code die ik gepost heb, is normaal gezien zoals het moet. In .NET 1.1 werkt het gewoon.

[jelmervos]

Dit is beter leesbaar.

[whoami]

Denk je nu echt dat ik die MSDN al lang niet bekeken had om te zien hoe het wel moet ?
Zoals ik al zei: die config is normaal gezien gewoon goed.

[whoami]

Ik heb de oplossing ondertussen gevonden.

Met de configuratie-file is er, zoals ik reeds verwachtte helemaal niks mis. Bleek dat ik ergens anders nog een syntax error had in m'n code, en die veroorzaakte die foutmelding mbt tot de config. file.
Eens die syntax error opgelost was, had ik ook die error niet meer die sloeg op de config file.

Eigenlijk vind ik dat best vreemd; een syntax error in m'n code zorgt ervoor dat vs.net begint te miepen over een 'fout in m'n config-file', terwijl er helemaal geen fout is.
Het ergelijke is dan ook nog eens dat die melding gewoon voor al m'n echte errors komt te staan.

[H!GHGuY]

Wat ik kon terugvinden op google was dat de .NET 1.1 manier in .NET 2.0 deprecated is.

misschien moet je daar in je code dan ook maar rekening mee gaan houden.

[whoami]

Heb je daar nog een linkje van ?
Ik weet dat het gebruik van ConfigurationSettings.AppSettings in .NET 2.0 deprecated is, maar dat dit ook voor de customSections zo zou zijn, zou me toch wel verbazen.
Als je kijkt in de machine.config (van .NET 2.0) bv, dan zie je dat daar ook nog gebruik gemaakt wordt van configSections.

[GrimaceODespair]

whoami schreef op zaterdag 18 februari 2006 @ 10:50:
Eigenlijk vind ik dat best vreemd; een syntax error in m'n code zorgt ervoor dat vs.net begint te miepen over een 'fout in m'n config-file', terwijl er helemaal geen fout is.
Het ergelijke is dan ook nog eens dat die melding gewoon voor al m'n echte errors komt te staan.

Volgens mij is het niet zo vreemd volgens MS-logica. Hij gaat, nadat alle fouten bekend zijn, altijd die fouten sorteren. Ik heb alleen nooit uitgezocht wat de volgorde is, maar het zal wel iets zijn van "eerst op prioriteit, dan op naam".

Hetzelfde kom je ook tegen wanneer je gaat compileren. Zit je een half uur naar een functieaanroep te staren, tot blijkt dat in de functie zelf een syntax fout zat, maar die VS later in de lijst weergeeft. Alleen kun je bij het compileren de volgorde van de fouten nog controleren in het Output window, maar dat is in jouw geval dus nvt.

[whoami]

Maar, waarom gebeurt dit dan niet in vs.net 2003.

En die config file is geeneens fout.

[H!GHGuY]

quote van die spaanse site die jij niet wou bezoeken:

Tuesday, January 31, 2006 #
IConfiguartionSectionHandler... in lista per la deprecazione!

IConfiguartionSectionHandler e la possibilità di customizzare sezioni del file di configurazione è una della cose che mi sono sempre piaciute! Con la nuova versione del framework e i generics è/sarebbe possibile scrivere devvero velocemente un IConfiguartionSectionHandler, ecco come faccio:

1. Defisco lo schema xsd della mia sezione (MySectionSchema.xsd)
2. Genero le classi per la sezializzazione (MySectionSchema.cs) con xsd.exe, che ho a portata di menù
3. Definisco il mio handler sfruttando una classe base così definita:

public abstract class ConfigurationSectionHandler<T> : IConfigurationSectionHandler
{
#region IConfigurationSectionHandler Members
object IConfigurationSectionHandler.Create(object parent, object configContext, System.Xml.XmlNode section)
{
XmlSerializer ser = new XmlSerializer(typeof(T), new XmlRootAttribute(section.Name));
XmlNodeReader reader = new XmlNodeReader(section);
return ser.Deserialize(reader);
}
#endregion
}

...la classe così fatta potrebbe dare dei problemi in caso di namespace specializzati per cui per fare le cose fatte bene si potrebbe/dovrebbe scrivere anche così:

public abstract class ConfigurationSectionHandler<T> : IConfigurationSectionHandler
{
#region IConfigurationSectionHandler Members
object IConfigurationSectionHandler.Create(object parent, object configContext, System.Xml.XmlNode section)
{
XmlSerializer ser = new XmlSerializer(
typeof(T),
new XmlAttributeOverrides(),
new Type[]{},
new XmlRootAttribute(section.Name),
section.NamespaceURI);
XmlNodeReader reader = new XmlNodeReader(section);
return ser.Deserialize(reader);
}
#endregion
}

4. Una Riga per la definizione della classe concreta:

public class MyConfigSectionHandler: ConfigurationSectionHandler<MySectionSchema>{}

Purtoppo a volte uno è tutto intento nel scoprire le funzionalità tanto pubblicizzate del nuovo framework che le cose banali/marginali finisco per sfuggirgli. E infatti qualche settimana fà discutendo sul newsgroup ho avuto la tremenda notizia che tale modalità di operare verrà deprecata anche se le classi non sono marcate come Obsolete... e infatti sul MSDN tristemente leggo:


"This topic uses the System.Configuration.IConfigurationSectionHandler interface, which has been deprecated in the .NET Framework version 2.0. For an example that uses the System.Configuration.ConfigurationSection class, see How to: Create Custom Configuration Sections Using ConfigurationSection. If you use the following code examples, please build them with the .NET Framework version 1.0 or 1.1." (http://msdn2.microsoft.com/en-us/library/ms228056.aspx)


Si certo esistono le nuove classi per la gestione del config sono ben fatte e piene di nuove potenzialità ma come ho detto in un mio suggerimento su lady bug, "IConfiguartionSectionHandler, why deprecated?" non capisco perchè deprecare tale modalità in quanto comunque è sistema pratico e veloce... sebbene gli esempi di MSDN lo facciamo apparire ostico e avanzato! Quindi perchè non matenere tutte e due le possibilità? Beh comunque qualcuno mi ha risposto - non so se per cortesia o perchè davvero interssato - dicendo che terranno in considarazione - a momento debito - il mio suggerimento... bah incrociamo le dita :-p Lunga vita a IConfigurationSectionHandler!

[whoami]

Het is die IConfigurationSectionHandler interface die deprecated is, maar niet het gebruik van configSections in de config-file.
Dat wil dus niet zeggen dat je geen custom configSections meer kunt aanmaken in je config. file.
Het is enkel die IConfigurationSectionHandler interface die deprecated is, omdat er nu in .NET 2.0 een class is die System.Configuration.ConfigurationSection heet, die de IConfigurationSectionHandler vervangt.

Zoek maar eens in de MSDN die ConfigurationSection class op; er staat daar een volledig voorbeeld van uitgewerkt, incl. een voorbeeld van een custom configSection in de configuration file. Dat -dat gedeelte van de config file- is nog gewoon hetzelfde gebleven.

[GrimaceODespair]

whoami schreef op zaterdag 18 februari 2006 @ 10:50:
Eigenlijk vind ik dat best vreemd; een syntax error in m'n code zorgt ervoor dat vs.net begint te miepen over een 'fout in m'n config-file', terwijl er helemaal geen fout is.
Het ergelijke is dan ook nog eens dat die melding gewoon voor al m'n echte errors komt te staan.

Mijn 2 centen:
VS gebruikt de code van je configSection handler ook designtime, zoals met controls. Als je dus een syntax-fout hebt die ervoor zorgt dat VS.NET de configSection niet kan compileren, breek je de designtime functionaliteit waarmee custom sections gevalideerd worden. Zoiets schat ik.

Maar wanneer krijg je die fout dan? Aangezien een syntaxfout aan de basis ligt, ga ik ervan uit dat VS.NET zelf kloeg?

[Verwijderd]

De error die je ziet is vermoedelijk geen error, maar een warning. Die zie je alleen na een full (re)build. Als je gaat debuggen zie geen error list wanneer er alleen warnings instaan.

De NameValueSectionHandler waarnaar je verwijst in je <section> is gebaseerd op IConfigurationSectionHandler, die dus deprecated is. Je moet dus een ConfigurationSection-gebaseerde class gebruiken. Ik zie alleen niet direct een alternatief voor een NameValueSection, misschien moet je er zelf een maken.

[Not Pingu]

HIGHGuY schreef op zondag 19 februari 2006 @ 11:00:
quote van die spaanse site die jij niet wou bezoeken:

[...]

offtopic:
Het is Italiaans

[H!GHGuY]

whoami schreef op zondag 19 februari 2006 @ 11:05:
Het is die IConfigurationSectionHandler interface die deprecated is, maar niet het gebruik van configSections in de config-file.
Dat wil dus niet zeggen dat je geen custom configSections meer kunt aanmaken in je config. file.
Het is enkel die IConfigurationSectionHandler interface die deprecated is, omdat er nu in .NET 2.0 een class is die <code>System.Configuration.ConfigurationSection</code> heet, die de IConfigurationSectionHandler vervangt.

Zoek maar eens in de MSDN die ConfigurationSection class op; er staat daar een volledig voorbeeld van uitgewerkt, incl. een voorbeeld van een custom configSection in de configuration file. Dat -dat gedeelte van de config file- is nog gewoon hetzelfde gebleven.

dat is ook wat ik bedoelde en dat is ook wat op die SpaanseItaliaanse site staat...
in plaats van je IConfigurationSectionHandler moet je nu blijkbaar een xsd schrijven of zo
en gebruik maken van een generic class.

[whoami]

Nee, dat moet ik niet want het hele boeltje werkt dus zoals ik het hier gepost heb.

Het gaat er dus om dat ik een syntax error had in m'n code, en dat die syntax error er ook voor zorgde dat ik de foutmelding ~die ik in m'n startpost vernoemde~ als eerste in m'n error-list te zien kreeg. Een foutmelding die eigenlijk niets van doen heeft met die syntax error.
Het was trouwens ook geen warning, want ik heb 'treat warnings as errors' aanstaan.

[Predje]

whoami schreef op maandag 20 februari 2006 @ 21:52:
Nee, dat moet ik niet want het hele boeltje werkt dus zoals ik het hier gepost heb.

Het gaat er dus om dat ik een syntax error had in m'n code, en dat die syntax error er ook voor zorgde dat ik de foutmelding ~die ik in m'n startpost vernoemde~ als eerste in m'n error-list te zien kreeg. Een foutmelding die eigenlijk niets van doen heeft met die syntax error.
Het was trouwens ook geen warning, want ik heb 'treat warnings as errors' aanstaan.

Dit heb ik ook gehad; krijg je een error die eigelijk nergens opslaat.
Vind ik persoonlijk een enorm slechte zaak, gezien het feit dat ik vind dat je blindelings op je errors moet kunnen vertrouwen. Anders wordt je echt gewoon op het verkeerde pad gezet en dat kan je enorm veel tijd kosten.

[Alex]

Misschien een idee om de code van de EntLib 2.0 er eventjes bij te pakken?
Edit: linkje

[ Voor 46% gewijzigd door Alex op 21-02-2006 12:53 ]