[C#]Not marked as serializable

[Verwijderd]

Ik ben nu al een paar dagen aan het worstelen met mijn set-up programma. Ik heb hierover ook al een topic gemaakt: Verwijderd in "\[VS2008, C#]Custom install"
Het probleem wat ik daar had is inmiddels opgelost.

Het probleem is nu dat de gehele set-up wordt doorlopen. Alle custom actions zijn uitgevoerd en dan krijg ik deze foutmelding:

code:

Het type ...myLogger in assembly ... is niet als serialiseerbaar gemarkeerd.

En daarna deze:

code:

Onverwachte bestandseinde aangetroffen bij parsen van Name. Regel 25, positie 18.

Ondanks dat de installatie is goed gegaan, veroorzaakt bovenstaande errors een rollback van de installatie.

Mijn logger classe hoeft ook helemaal niet serializable te zijn, dus snap ik de foutmelding niet.
In mijn code is regel 25 niets zinnigs: een '{' en ik gebruik nergens Name.
Verder bevat mijn logfile maar 18 regels.

Hier is mijn logger classe:

C#:

public class myLogger : IDisposable
{
    StreamWriter _sw = null;
    private string _logfilename;

    public string Logfilename
    {
        get { return _logfilename; }
    }

    ~myLogger()
    {
        this.Dispose(false);
    }

    public myLogger(string logfilename)
    {
        try
        {
            this._sw = new StreamWriter(logfilename, false);
            this._sw.AutoFlush = true;

            //Save for later:
            this._logfilename = logfilename;
       
            //Write text:
            this.Dbg("Start of logging.");
        }
        catch (Exception ex)
        {
            this.Dbg("Error in _logger.StartToFile: " + ex.ToString());
            throw ex;
        }
    }

    public void Dbg(string message)
    {
        if (this._sw == null)
            throw new InstallException("Cannot write to logfile.");

        try
        {
            string tekst = DateTime.Now + " "
                         + message;
            this._sw.WriteLine(tekst);
        }
        catch (Exception ex)
        {
            if (this._sw != null)
            {
                string tekst = DateTime.Now + " "
                       + "Error in _logger.Dbg: " + ex.ToString();
                this._sw.WriteLine(tekst);
            }                
            throw ex;
        }
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            //call dispose on any objects referenced by this object
            if (this._sw != null)
            {
                _sw.WriteLine("Final flush");
                this._sw.Flush();
                _sw.WriteLine("Closing logfile");
                this._sw.Close();
                this._sw.Dispose();
                this._sw = null;
            }
        }
    }

    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }
}

Uiteraard heb ik al via Google op "not marked serializable" gezocht, maar niets kunnen vinden wat op dit probleem lijkt.

Graag even een duwtje in de goede richting.

[whoami]

Vreemd.
Gewoon om te testen: wat gebeurd er als je jouw class toch als Serializable markeert ?

[Verwijderd]

Hoe doe ik dat dan?
Ik heb al geprobeerd door [Serializable] boven

C#:

public class myLogger : IDisposable

te zetten, maar dan krijg ik een andere foutmelding:
Parsefout: Er is geen assembly gekoppeld aan XML-sleutel ...myLogger

Dus dat helpt ook niet. Of markeer ik mijn classe niet op de juiste manier als Serializable?

[Haan]

Is die tweede melding een regel in je log bestand of komt die toevallig ergens anders vandaan?

Het [Serializable] attribuut boven je class zetten zou genoeg moeten zijn. Wat gebeurt er als je alle dispose code en de destructor wegsloopt uit je class? (lijkt mij een beetje overkill voor een simpele logger)

[Verwijderd]

Heb je "System" tussen je using's staan? Dan zou het op die manier moeten werken ja...

[whoami]

Haan schreef op zaterdag 12 juli 2008 @ 01:44:


Wat gebeurt er als je alle dispose code en de destructor wegsloopt uit je class? (lijkt mij een beetje overkill voor een simpele logger)

Waarom zou dat overkill zijn ? Zijn logger gebruikt classes die ook disposable zijn, dus je moet er zowiezo voor zorgen dat die resources ook gedisposed worden.

Heb je al eens geprobeerd om je solution te 'cleanen' ?

[Haan]

Ik dacht dat de GC daar zelf wel voor zorgt, of ik ben in de war met Java. Anders moet ik ook maar eens wat code aanpassen

[Verwijderd]

Haan schreef op zaterdag 12 juli 2008 @ 10:23:
Ik dacht dat de GC daar zelf wel voor zorgt, of ik ben in de war met Java. Anders moet ik ook maar eens wat code aanpassen

Doet hij ook wel. Expliciet managed resources disposen is ook niet verplicht. Echter, ze zijn disposable omdat die class of onderliggende classes unmanaged resources gebruiken. Vaak wil je die zo snel mogelijk vrijgeven. In dit geval houdt StreamWriter een file handle vast. Ik hanteer altijd de vuistregel dat als een class belangrijke unmanaged resources gebruikt (sockets, file handles, veel unmanaged geheugen, etc), deze zo snel mogelijk vrij te geven. Het hele using statement is daar ook voor uitgevonden: direct disposen als je iets niet meer nodig hebt. Maar nogmaals, het is niet verplicht, de garbage collector doet het vroeg of laat ook.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 94% gewijzigd door Ruudjah op 02-12-2009 00:11 ]

[Verwijderd]

Ruudjah schreef op zaterdag 12 juli 2008 @ 15:03:
even checken voor de zekerheid/volledigheid:

[...]

Je hebt wel

C#:

using System.Runtime.Serialization;

bovenin je class gezet?

Nergens voor nodig, zoals ik eerder in dit topic al noemde hoeft alleen "System" er te staan om de [Serializable] parameter te gebruiken.

In de namespace die jij noemt zitten bijvoorbeeld de formatters om objecten te serializen, en voor zover ik kan zien aan de gepostte code wil de TS dat nergens doen .

[ Voor 7% gewijzigd door Verwijderd op 12-07-2008 15:25 ]

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 89% gewijzigd door Ruudjah op 02-12-2009 00:11 ]

[dominic]

Misschien een stomme vraag wat niets met je probleem te maken heeft, maar waarom benader je de ene keer _sw via this._sw en de andere keer via _sw?

Het gebruik van this lijkt me compleet overbodig aangezien de StreamWriter _sw binnen de huidige class gedefinieerd wordt. Zou myLogger._sw dan niet netter staan dan this._sw?

_{Persoonlijk zou ik _sw gewoon direct benaderen wanneer je binnen dezelfde class bezig bent}

[ Voor 12% gewijzigd door dominic op 12-07-2008 17:23 ]

[Verwijderd]

dominic schreef op zaterdag 12 juli 2008 @ 17:22:
Misschien een stomme vraag wat niets met je probleem te maken heeft, maar waarom benader je de ene keer _sw via this._sw en de andere keer via _sw?

Opzich zit er geen verschil tussen this._field of _field, het is alleen een beetje inconsistent om het door elkaar te gebruiken.
Programmeer technisch maakt het niks uit (zolang je niet een parameter hebt in je methode/constructor met precies dezelfde naam).

Het gebruik van this lijkt me compleet overbodig aangezien de StreamWriter _sw binnen de huidige class gedefinieerd wordt. Zou myLogger._sw dan niet netter staan dan this._sw?

_{Persoonlijk zou ik _sw gewoon direct benaderen wanneer je binnen dezelfde class bezig bent}

myLogger._sw zal niet gaan, omdat je met die notatie een public static StreamWriter _sw zou moeten hebben .

Verder ben ik het wel met je eens, het gebruik van this is hier wellicht overbodig (maar kan wel gebruikt worden om de leesbaarheid te vergroten, of gewoon uit persoonlijke voorkeur).

[ Voor 5% gewijzigd door Verwijderd op 12-07-2008 17:31 ]

[H!GHGuY]

Controleer even of alle members (incl streamwriter) het Serializable attribuut hebben.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 94% gewijzigd door Ruudjah op 02-12-2009 00:11 ]

[whoami]

dominic schreef op zaterdag 12 juli 2008 @ 17:22:
Misschien een stomme vraag wat niets met je probleem te maken heeft, maar waarom benader je de ene keer _sw via this._sw en de andere keer via _sw?

Het gebruik van this lijkt me compleet overbodig aangezien de StreamWriter _sw binnen de huidige class gedefinieerd wordt. Zou myLogger._sw dan niet netter staan dan this._sw?

_{Persoonlijk zou ik _sw gewoon direct benaderen wanneer je binnen dezelfde class bezig bent}

_sw en this._sw is gewoon hetzelfde. Maakt niet uit of je er nu this voorzet of niet; da's gewoon een verwijzing dat het een member is dan deze instantie. Of je dat er nu zet of niet, de compiler vertaalt dat gewoon naa dezelfde IL code ....

H!GHGuY schreef op zaterdag 12 juli 2008 @ 17:30:
Controleer even of alle members (incl streamwriter) het Serializable attribuut hebben.

Serializable definieer je op class niveau en afaik kan je dat zelfs niet op member niveau definieren ... Dat heeft trouwens ook geen zin. Als je class niet als serializable gedefinieerd is, dan is ze ook niet serializable whatever je er mee doet.

Los daarvan vraag ik me af waarom die installer zou vereisen dat die class serializable is .... 't Is toch niet zo dat er met remoting oid gewerkt wordt ofzo ? ..

Zowiezo zou ik eens proberen om het dutch language pack dat je evt geinstalleerd hebt, te de-installen en eens te googlen op de engelstalige foutmelding icm met de term custom install of custom install action ?

[ Voor 33% gewijzigd door whoami op 12-07-2008 23:04 ]

[Verwijderd]

whoami schreef op zaterdag 12 juli 2008 @ 23:00:
[...]


Serializable definieer je op class niveau en afaik kan je dat zelfs niet op member niveau definieren ... Dat heeft trouwens ook geen zin. Als je class niet als serializable gedefinieerd is, dan is ze ook niet serializable whatever je er mee doet.

Als je klasse members heeft van andere klassen (in dit geval heeft myLogger dus een member van het type StreamWriter), en je wilt myLogger Serializen, dan moeten ook alle member klassen Serializable zijn.

[ Voor 24% gewijzigd door Verwijderd op 13-07-2008 00:32 ]

[whoami]

Verwijderd schreef op zondag 13 juli 2008 @ 00:29:
[...]

Als je klasse members heeft van andere klassen (in dit geval heeft myLogger dus een member van het type SteamWriter), en je wilt myLogger Serializen, dan moeten ook alle member klassen Serializable zijn.

Da's wat ik zeg ... Echter, jij kan er niet voor zorgen dat StreamWriter serializable is, want dat definieer je op type niveau, en niet op member niveau.

@TS: wat is het versienummer dat je aan je assembly geeft, en wat is de 'Version' die je gegeven hebt aan je install project ?

[ Voor 11% gewijzigd door whoami op 13-07-2008 00:36 ]

[Verwijderd]

whoami schreef op zondag 13 juli 2008 @ 00:32:
[...]

Da's wat ik zeg ... Echter, jij kan er niet voor zorgen dat StreamWriter serializable is, want dat definieer je op type niveau, en niet op member niveau.

Inderdaad, maar ik wilde alleen even aangeven wat H!GHGuY bedoelde .

Verder is dit onderstaande punt wat jij noemt het eerste wat we opgehelderd moeten krijgen, want het is mij inderdaad ook een vraag waarom er uberhaupt een poging tot Serialization wordt gedaan...

whoami schreef op zaterdag 12 juli 2008 @ 23:00:
[...]

Los daarvan vraag ik me af waarom die installer zou vereisen dat die class serializable is .... 't Is toch niet zo dat er met remoting oid gewerkt wordt ofzo ? ..

[Verwijderd]

Goed nieuws. Ik ben van die vreemde foutmelding af.
Wat heb ik nu gedaan?
Ik heb eerst een console applicatie gemaakt die de logger gebruikt op dezelfde manier als dat de installer dat doet (zou moeten doen).
Het resultaat was dat de logfile werd gemaakt en dat er geen foutmelding kwam. Daaruit concludeerde ik dat het probleem niet in de log classe zit maar in de manier waarop ik die aanroep/gebruik.
Zoals negerzoen voorstelde heb ik mijn log-object nu met het using statement gebruikt. En alleen nog maar in de install en uninstall methods, dus niet meer in de commit en rollback methods.
Dit heeft er voor gezorgd dat de foutmeldingen weg blijven. Wat nu precies de oorzaak was, weet ik niet maar het zal wel een combi zijn van de log classe gebruiken terwijl die er niet meer is (in de commit en de rollback methods) en het te vroeg of te laat disposen van het object.
Overigens gebruik ik nog steeds niets met serializable, ook geen attributen.

Om nog even terug te komen op wel of niet this. In mijn eerste code heb ik dat inderdaad niet consequent toe gepast en het blijft een kwestie van smaak of je het wel of niet gebruikt.
Ik probeer tegenwoordig zoveel mogelijk StyleCop van Microsoft te gebruiken: http://blogs.msdn.com/sourceanalysis
Dat zorgt er in ieder geval voor dat mijn code wat consequenter geschreven is/wordt

Iedereen bedankt voor het meedenken.

Paul

[vorlox]

offtopic:
Het gebruik van this is eigenlijk redundant. Ik zelf gebruik resharper (niet gratis) welke je erg helpt bij het clean houden van code...erug relaxed ik heb veel geleerd van die tool.

[Verwijderd]

Resharper is wel fijn inderdaad, maar die geeft ook aan dat base. calls redundant zijn...maar soms is het toch wel fijn om te weten dat je een property/methode van je base type aanspreekt .

Verder is this. natuurlijk niet altijd redundant...maar in de meeste gevallen wel.

Als je bijvoorbeeld zo werkt is het hebben van een this. wel fijn, en alles behalve redundant :

C#:

class bla
{
  private int getal;
  
  public bla(int getal)
  {
    this.getal = getal;
  }
}

[ Voor 44% gewijzigd door Verwijderd op 15-07-2008 00:00 ]

[vorlox]

Verwijderd schreef op maandag 14 juli 2008 @ 23:58:
Resharper is wel fijn inderdaad, maar die geeft ook aan dat base. calls redundant zijn...maar soms is het toch wel fijn om te weten dat je een property/methode van je base type aanspreekt .

Verder is this. natuurlijk niet altijd redundant...maar in de meeste gevallen wel.

Als je bijvoorbeeld zo werkt is het hebben van een this. wel fijn, en alles behalve redundant :

C#:

class bla
{
  private int getal;
  
  public bla(int getal)
  {
    this.getal = getal;
  }
}

Haha schitterend..point taken

[DrDelete]

Verwijderd schreef op zaterdag 12 juli 2008 @ 12:47:
[...]

Doet hij ook wel. Expliciet managed resources disposen is ook niet verplicht. Echter, ze zijn disposable omdat die class of onderliggende classes unmanaged resources gebruiken. Vaak wil je die zo snel mogelijk vrijgeven. In dit geval houdt StreamWriter een file handle vast. Ik hanteer altijd de vuistregel dat als een class belangrijke unmanaged resources gebruikt (sockets, file handles, veel unmanaged geheugen, etc), deze zo snel mogelijk vrij te geven. Het hele using statement is daar ook voor uitgevonden: direct disposen als je iets niet meer nodig hebt. Maar nogmaals, het is niet verplicht, de garbage collector doet het vroeg of laat ook.

Heel simpel: heb je members op je class die IDisposable implementeren, dan moet jouw class ook IDisposable implementeren anders verbreek je de IDisposable hierarchie.

Als je IDisposable introduceert voor jouw class moet je een finalizer (~classname) implementeren om er voor te zorgen dat de resources opgeruimd worden als ooit de GC de boel gaat opruimen.

Indien je erft van een class waar een protected Dispose method al inzit (zodat je een override kunt uitvoeren), dan hoef je geen finalizer zelf te introduceren (ze kosten performance!): als het goed is heeft die baseclass de finalizer al gemaakt en geeft een schop aan de Dispose protected method.

[EfBe]

DrDelete schreef op dinsdag 15 juli 2008 @ 12:04:
[...]
Heel simpel: heb je members op je class die IDisposable implementeren, dan moet jouw class ook IDisposable implementeren anders verbreek je de IDisposable hierarchie.

dat hoeft niet per se, jouw class kan Dispose aanroepen op die members wanneer dat nodig mocht zijn, bv in het geval van een contained connection object.

Als je IDisposable introduceert voor jouw class moet je een finalizer (~classname) implementeren om er voor te zorgen dat de resources opgeruimd worden als ooit de GC de boel gaat opruimen.

De finalizer is niet de clean-up method, maar een method die aangeroepen wordt wanneer Dispose zelf niet is aangeroepen (daarom moet je jezelf ook uit de finalizer queue halen in je Dispose method). Je kunt daarin ook alleen unmanaged resources direct opruimen. M.a.w.: heb jij een managed object met daarin unmanaged resources, dan kun je daar niet bij in de Finalize override, want je kunt geen managed objects referencing in een finalizer call.

Opruimen doe je dus in de protected Dispose(bool) method

Overigens is dispose een achterlijk pattern. Het is fragiel en levert geen solide code op, want je hoeft maar 1 fout te maken en je bent de klos. Beter was geweest als men gewoon new/delete had aangenomen zoals in C++ icm destructors. het is nl. niet zo dat je nu memory leaks voorkomt doordat er een GC is, memory leaks zijn zo gemaakt, en de GC kijkt er naar en haalt zn schouders op.

[DrDelete]

EfBe schreef op dinsdag 15 juli 2008 @ 13:30:
[...]

dat hoeft niet per se, jouw class kan Dispose aanroepen op die members wanneer dat nodig mocht zijn, bv in het geval van een contained connection object.

Als ik een private member (Bijv. een Timer, die IDisposable implementeert) heb op de class, dan moet ik die echter wel in in een eigen Dispose method opruimen anders verbreek je de IDisposable keten

Hier wat nuttige info: http://msdn.microsoft.com/en-us/library/b1yfkh5e(vs.71).aspx

[ Voor 8% gewijzigd door DrDelete op 15-07-2008 16:13 ]

[farlane]

EfBe schreef op dinsdag 15 juli 2008 @ 13:30:
Beter was geweest als men gewoon new/delete had aangenomen zoals in C++ icm destructors.

Amen