[C#] The type initializer for 'MyClass' threw an exception

[Marc.O]

Hallo Tweakers,

Ik loop tegen een exception aan die ik niet op kan lossen.
Ik krijg de exception bij het aanroepen van de constructor van een control.
De control heeft 2 constructors.

C#:

//call
ControlA ctrl = new ControlA(strS, intI, boolB);

public partial class ControlA : UserControl
{
  public ControlA()
  {
    InitializeComponent();          
  }

  public ControlA(string str, int i, Boolean b) 
  {
    this.str = str;
    this.i = i;
    this.b = b;

    InitializeComponent();
    headerFont = new Font("Courier New", headerTextSize, FontStyle.Regular);
  }
}

Dit geeft de volgende exception:
"The type initializer for 'ControlA' threw an exception"

Met de InnerException:
"Value cannot be null.\r\nParameter name: method"

Ik heb een breakpoint op de aanroep van de constructor gezet en op beide constructors. Als ik een step maak van de aanroep krijg ik de exception. Ik kom nooit in de preakpoints van een van de constructors.

De debug folder bevat alle relevante bestanden en de cpu properties van alle projecten staan op "any cpu" (dit zou volgens google het probleem op kunnen lossen).

Heeft iemand een idee waar het probleem ligt of waar ik het moet zoeken?

[Cyphax]

Kom je niet in de knoei met System.Web.UI.Control nou? Welke Control heb je daar precies bij "new Control(...)"?
Je hebt vast using System.Web.UI bovenin staan, raakt ie niet gewoon in de war nu?

[Cor453]

Ik denk dat Cyphax gelijk heeft: als je de naam Control nu eens verandert in iets wat specifieker is en minder conflicten gaat geven? Werkt het dan?

[Marc.O]

Het is een custom control in een windows forms application.

Edit: Sorry had ik erbij moeten zeggen. Control is niet de naam die ik gebruik maar gewoon hier even een voorbeeld.

[ Voor 50% gewijzigd door Marc.O op 23-09-2013 17:03 ]

[Cyphax]

Oh een Windows Forms applicatie... hmmm. Ik kan het niet uit deze code halen. Het kon weleens misgaan bij InitializeComponent(), die leest weer een YAML-bestandje uit, maar daar post je verder niets van dus da's gokken.

Kijk eens op http://stackoverflow.com/...-and-how-does-it-work-wpf of je hier niet een aanknopingspunt vindt.

[.oisyn]

Dat is een post over WPF, hij zegt nou juist dat het om WinForms gaat

[Woy]

Waarschijnlijk heb je een static constructor of het gaat fout bij de initialisatie van een van de static fields van de class ( Die roepen misschien weer een andere Constructur aan ).

[pedorus]

Ergens in een static field of static constructor laad je waarschijnlijk wat xml in waarbij het veld "method" ontbreekt. Waar dit precies gebeurd blijkt niet uit je geposte code (want daar is niets static).

[STW]

Ik zou vanuit het omschrijven naar:

C#:

//call
ControlA ctrl = new ControlA(strS, intI, boolB);

public partial class ControlA : UserControl
{
  public ControlA()
  {
    InitializeComponent();          
  }

  public ControlA(string str, int i, Boolean b)
    :this() 
  {
    this.str = str;
    this.i = i;
    this.b = b;

    headerFont = new Font("Courier New", headerTextSize, FontStyle.Regular);
  }
}

Vanuit je tweede constructor als eerste de default constructor aanroepen. Volgens mij zou dat je probleem moeten oplossen.

[ Voor 0% gewijzigd door STW op 23-09-2013 20:58 . Reden: layout aanpassing ]

[BasieP]

pedorus schreef op maandag 23 september 2013 @ 18:42:
Ergens in een static field of static constructor laad je waarschijnlijk wat xml in waarbij het veld "method" ontbreekt. Waar dit precies gebeurd blijkt niet uit je geposte code (want daar is niets static).

sinds wanneer leest winforms xml in?


@TS:
Wat STW hierboven doet is (op een nette manier) zorgen dat je initialize components methode (zie je andere partial class blabla.designer.cs) als eerste wordt uitgevoerd.

In je voorbeeld is dit niet zo, dit is wel een best practise.


Ik zit me af te vragen of jou voorbeeld echt fout gaat.
Dat wat je in de topic-start hebt gepost gaat namelijk niet mis. Wellicht is het wat om een kleine testcase te bouwen die wel fout gaat


ow en nog een puntje (we zijn toch aan't mierenneuken):
gebruik je basic types of niet? volgens mij is het aan te raden om het wel te doen. Dus schrijf dan ook 'bool' en niet 'Boolean'

[ Voor 46% gewijzigd door BasieP op 23-09-2013 22:04 ]

[farlane]

Anders check even de code in de ControlA designer file.

[Marc.O]

@STW:
Ik heb het aangepast maar het helpt niet.

Het lijkt tussen de call en de uitvoering van de constructor fout te gaan. Zoals ik al zei heb ik een breakpoint op de call en de eerste regel van de constructor. Hij breakt wel op de call naar de constructor maar komt nooit in de breakpoint in de constructor.

Het rare is dat het in vorige releases altijd gewerkt heeft en dat er na mijn idee aan de code niks verandert is. Kan het misschien komen door verkeerde project instellingen?

[PdeBie]

Ik zal dan eerst maar eens kijken of het ook echt zo is dat er niets gewijzigd is. Soms valt er op punt A iets om, door een wijziging op punt B.

[JMaster]

Je hebt niet toevalligerwijs ergens een reference van ControlA naar je class die de call aanroept?

[Woy]

Marc.O schreef op dinsdag 24 september 2013 @ 10:23:
@STW:
Ik heb het aangepast maar het helpt niet.

Het lijkt tussen de call en de uitvoering van de constructor fout te gaan. Zoals ik al zei heb ik een breakpoint op de call en de eerste regel van de constructor. Hij breakt wel op de call naar de constructor maar komt nooit in de breakpoint in de constructor.

Het rare is dat het in vorige releases altijd gewerkt heeft en dat er na mijn idee aan de code niks verandert is. Kan het misschien komen door verkeerde project instellingen?

Zoals ik reeds hierboven aangaf gaat het fout bij het initialiseren van het Type, en dus waarschijnlijk een Static Constructor/Field. Op het punt waar je de constructor call maakt zal de eerste keer namelijk eerst het type geïnitialiseerd worden, maar dat gaat mis en dus kom je niet in de daadwerkelijke constructor. Maar ook met de exception die je hebt kun je natuurlijk gewoon de stacktrace kijken, en dus zo achterhalen op welke regel het mis gaat.

[Marc.O]

Woy je hebt helemaal gelijk. Het gaat mis op de volgende regel:

C#:

static MemCpyImpl memcpyimpl = (MemCpyImpl)Delegate.CreateDelegate(typeof(MemCpyImpl), typeof(Buffer).GetMethod("memcpyimpl", BindingFlags.Static | BindingFlags.NonPublic)); // throws exception.

private unsafe delegate void MemCpyImpl(byte* src, byte* dest, int len);

Blijkbaar kan hij "memcpyimpl" niet meer vinden? Hier is niks aan verandert tenopzichte van vorige wel werkende versies...

[Woy]

Marc.O schreef op dinsdag 24 september 2013 @ 11:38:
Blijkbaar kan hij "memcpyimpl" niet meer vinden?

Als je de daadwerkelijke exception ( InnerException ) dan bekijkt weet je echt wat er mis gaat.

Hier is niks aan verandert tenopzichte van vorige wel werkende versies...

Jij denkt dat er niks is veranderd, maar het resultaat toont aan dat er wel wat veranderd is

[Marc.O]

Woy schreef op dinsdag 24 september 2013 @ 11:41:
Jij denkt dat er niks is veranderd, maar het resultaat toont aan dat er wel wat veranderd is

Scherp

"methode" -> typeof(Buffer).GetMethod("memcpyimpl", BindingFlags.Static | BindingFlags.NonPublic) geeft inderdaad null terug wat in de inner exception staat. Rest alleen de vraag nog waarom...

[Woy]

Sowieso zie ik daar een probleem met de case, en je hebt natuurlijk altijd risico met het gebruiken van dergelijke non-public methodes. Die kunnen immers bij een update zomaar verdwijnen. Heb je bijvoorbeeld een update geïnstalleerd, of ben je overgestapt op een andere versie van het framework.

[PdeBie]

pdebie schreef op dinsdag 24 september 2013 @ 10:44:
Ik zal dan eerst maar eens kijken of het ook echt zo is dat er niets gewijzigd is. Soms valt er op punt A iets om, door een wijziging op punt B.

I repeat myself.....

[Marc.O]

Ik heb geen update gehad. En volgens de diff is er niks verandert in het project waar het in fout gaat.

Maar goed ik zag in http://stackoverflow.com/...ay-of-copying-arrays-in-c dat ik kan proberen of het met een blockCopy nog snel genoeg gaat.

[Woy]

Waarom gebruik je Buffer.BlockCopy überhaupt niet? Een dergelijke non-public functie is bijna nooit te verkiezen boven de normaal beschikbare API!

[Marc.O]

Tja dat is een goede vraag. Ik heb dit deel van het project niet zelf gemaakt maar ik denk dat het gedaan is omdat het een betere prestatie zou moeten leveren.

Ik ga het nu omschrijven naar de blockCopy. Bedankt voor alle hulp!

[ Voor 18% gewijzigd door Marc.O op 24-09-2013 13:04 ]

[BasieP]

leuk man.. c++ mannetjes die in managed code niet weten hoe iets moet en maar ranzige code schrijven zonder dit (blijkbaar) te documenteren