Inicjator typu dla „MyClass” zgłosił wyjątek

Oto mój kod usługi Windows. Podczas debugowania kodu pojawia się błąd / wyjątek:

Inicjator typu dla „CSMessageUtility.CSDetails” zgłosił wyjątek.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Linq;
using System.ServiceProcess;
using System.Text;
using System.IO;
using System.Threading;
using System.Windows;
using System.Windows.Forms;
using CSMessageUtility;

namespace CS_Data_Trasmmiting_Service
{
    public partial class svcCSWinServ : ServiceBase
    {
        //private string sLogFormat;
        //private string sErrorTime;
        private Thread new_thread;
        Logger logObject = new Logger();
        private bool isenable = true;

        public svcCSWinServ()
        {
            InitializeComponent();
            logObject.append("Initialize Service " + DateTime.Now.ToString(), 70);
            CheckForAlarms();
        }

        protected override void OnStart(string[] args)
        {
            try
            {
                new_thread = new Thread(new ThreadStart(CheckForAlarms));
                new_thread.Start();
            }
            catch
            {
            }

            logObject.append("Service Started successfully " + DateTime.Now.ToString(), 70);
        }

        protected override void OnStop()
        {
            try
            {
                isenable = false;
                new_thread.Abort();
            }
            catch
            {

            }
            logObject.append("Service Stopped successfully " + DateTime.Now.ToString(), 70);
        }


        void CheckForAlarms()
        {
            try
            {
                while (true)
                {
                    //if((DateTime.Now.ToString("HH:mm") == "18:00"))
                    //{

                        logObject.append("Start Sending Data " +DateTime.Now.ToString(), 70);
                        try
                        {
                            //SendAllInfo();
                            string str = CSMessageUtility.CSDetails.createDHSMessageFormat();
                            Thread.Sleep(2000);
                            string str1 = CSMessageUtility.CSDetails.createEALMessageFormat();
                            Thread.Sleep(2000);
                            string str2 = CSMessageUtility.CSDetails.createProductStatusMessageForamt();
                            Thread.Sleep(2000);
                            string str3 = CSMessageUtility.CSDetails.createEODMessageFormat();
                            Thread.Sleep(2000);
                            string str4 = CSDetails.createProductReceiptEntryatBOSMessageFormat();
                            Thread.Sleep(2000);
                            string str5 = CSMessageUtility.CSDetails.createProductSaleMessageFormat();
                            Thread.Sleep(2000);
                            string str6 = CSMessageUtility.CSDetails.createTotalizerExceptionMessageFormat();
                            Thread.Sleep(2000);
                            //CSMessageUtility.CSDetails.createDailyCOtransferMessageFormat();
                            //Thread.Sleep(2000);

                        }
                        catch (Exception ee)
                        {
                            logObject.append(ee.Message, 70);
                        }
                        logObject.append("Finished Sending Data " +DateTime.Now.ToString(), 70);
                        Thread.Sleep(3000);
                    //}
                    //Thread.Sleep(20000);
                }
            }
            catch (Exception ex)
            {
                logObject.append("Thread Exception: "+ ex.Message + " "+ DateTime.Now.ToString(), 70);

                try
                {
                    new_thread.Abort();
                }
                catch (Exception ex1)
                {
                    logObject.append("Thread Exception: " +ex1.Message + " " + DateTime.Now.ToString(), 70);
                }

                if (isenable == true)
                {
                    new_thread = new Thread(new ThreadStart(CheckForAlarms));
                    new_thread.Start();
                }
            }
        }
    }
}

Sprawdź InnerExceptionwłaściwość TypeInitializationException; może zawierać informacje o podstawowym problemie i dokładnie tam, gdzie wystąpił.

Ten problem może zostać spowodowany, jeśli klasa spróbuje uzyskać wartość klucza w pliku web.config lub app.config, którego tam nie ma.

np
. Klasa ma zmienną statyczną

private static string ClientID = System.Configuration.ConfigurationSettings.AppSettings["GoogleCalendarApplicationClientID"].ToString();

Ale plik web.config nie zawiera GoogleCalendarApplicationClientIDklucza

Błąd zostanie zgłoszony przy każdym wywołaniu funkcji statycznej lub tworzeniu instancji klasy

The type initializer for 'CSMessageUtility.CSDetails' threw an exception. oznacza, że ​​konstruktor statyczny w tej klasie zgłosił wyjątek - należy więc spojrzeć albo w konstruktora statycznego klasy CSDetails, albo w inicjalizacji dowolnego statycznego elementu tej klasy.

Zetknąłem się z tym samym problemem, kiedy korzystałem z metod statycznych w klasie Util, tak jak ty użyłeś „CSMessageUtility.CSDetails”.

Problem polegał na tym, że podczas statycznej inicjalizacji klasy (za pomocą konstruktora statycznego) środowisko inicjuje również statyczne zmienne (pola) w klasie. Miałem zmienną statyczną, która próbuje odczytać wartości z app.config, a app.config brakowało odpowiednich ustawień, co spowodowało nieobsługiwany wyjątek. Spowodowało to, że „Odwołanie do obiektu nie zostało ustawione na instancję obiektu”. jako wewnętrzny wyjątek.

Inną sprawą do sprawdzenia, kiedy zostaną zgłoszone błędy inicjalizacji, będzie sprawdzenie, czy docelowa wersja .NET jest zainstalowana na serwerze. Możesz kliknąć projekt prawym przyciskiem myszy i zobaczyć, do której wersji .NET skierowana jest aplikacja.

Miałem ten sam problem spowodowany posiadaniem dwóch takich samych właściwości konfiguracyjnych (które pasują do pliku app.config):

    [ConfigurationProperty("TransferTimeValidity")]

Innym scenariuszem, który może być przyczyną, jest fragment kodu wywołujący:

string sParam = **ConfigurationManager.AppSettings["SOME_PARAM"].ToString();

Pamiętaj, że musisz użyć tego OWSTIMER.EXE.CONFIGpliku do ustawień pliku konfiguracyjnego. Miałem App.configplik, który próbowałem odczytać, i otrzymywałem ten błąd, ponieważ podczas tworzenia instancji mojej pracy miałem wiersz w kodzie, który odnosił się do Connfiguration.AppSettings& Configuration.ConnectionStrings. Tylko upewnij się, że idziesz ścieżką:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN

i umieść ustawienia konfiguracji w OWSTIMER.EXE.CONFIGpliku.

Może się to zdarzyć, jeśli masz właściwość zależności zarejestrowaną na niewłaściwym typie właściciela (argument ownerType).

Zauważ, że SomeOtherControl powinien być YourControl.

public partial class YourControl
{
    public bool Enabled
    {
        get { return (bool)GetValue(EnabledProperty);   }
        set { SetValue(EnabledProperty, value); }
    }
    public static readonly DependencyProperty EnabledProperty =
        DependencyProperty.Register(nameof(Enabled), typeof(bool), typeof(SomeOtherControl), new PropertyMetadata(false));
}

Jeśli z jakiegokolwiek powodu dojdzie do awarii zasilania lub nastąpi awaria programu Visual Studio IDE, może to powodować ten problem w bin / debug bin / release ...

Wystarczy usunąć zawartość i ponownie skompilować (z własnego doświadczenia, gdy mój palec u nogi naciśnie przycisk resetowania!)

Miałem inną, ale wciąż powiązaną konfigurację.

Może to być sekcja konfiguracji niestandardowej, która nie została zadeklarowana w configSections .

Po prostu zadeklaruj sekcję, a błąd powinien rozwiązać się sam.

Napotkałem ten problem z powodu niedopasowania między wersjami wykonawczymi zestawów. Sprawdź wersje środowiska wykonawczego głównego zestawu (aplikacji wywołującej) i odpowiedniego zestawu

Jak mówi błąd, inicjalizacja typu / klasy nie powiodła się. Zwykle dzieje się tak, gdy istnieje jakiś wyjątek w konstruktorze klasy. Najczęstszym powodem jest przypisanie pewnej wartości do odczytu konstruktora z pliku konfiguracyjnego, aw pliku konfiguracyjnym brakuje tych wartości.

W moim przypadku wystąpił błąd w Logger.Create w bibliotece klas, która była używana przez moją główną (konsolową) aplikację. Problem polegał na tym, że zapomniałem dodać odniesienie do pliku NLog.dll w mojej aplikacji konsoli. Dodanie odwołania do poprawnej wersji biblioteki .NET Framework rozwiązało problem.

Miałem taki przypadek w projekcie WPF. Mój problem dotyczył następującej linii:

DataTable myTable = FillTable(strMySqlQuery);

Gdzie FillTable()zwrócił tabelę danych na podstawie ciągu zapytania SQL. Gdybym zrobił opcję „kopiuj wyjątek do schowka”, myślę, że tak było i wkleiłem ją do Notatnika, mógłbym zobaczyć komunikat. Dla mnie tak było The input is not a valid Base-64 string as it contains a non-base 64 character.

Mój rzeczywisty problem nie był taki, że ciąg kwerendy miał coś, co nie powinno tam być, jak myślałem, bo string strMySqlQuery = "SELECT * FROM My_Table"był moim ciąg i myśli może to być *albo _, ale rzeczywisty problem był FillTable(), gdzie miałem wezwanie do innego funkcja, GetConnection()która zwróciła OracleConnectionobiekt, aby go otworzyć oraz pobrać i zwrócić tabelę danych. Wewnątrz GetConnection()otrzymywałem app.configparametry mojego ciągu połączenia i miałem jeden z nich błędnie nazwany, więc ustawiał wartość zerową hasła konta usługi i nie nawiązywał połączenia DB. Dlatego nie zawsze błąd jest poprawny we wszystkich okolicznościach. Najlepiej zanurzyć się w funkcji, w której występuje błąd, i debugować krok po kroku i upewnić się, że wszystkie wartości wypełniają się zgodnie z oczekiwaniami.

Ja również spotkałem się z tym błędem w dwóch sytuacjach

1. Podczas przekierowywania z warstwy BAL na warstwę DAL napotkałem ten wyjątek. Wyjątek wewnętrzny mówi, że „błąd odwołania do obiektu”.

2. Web.Config klucz pliku nie pasuje.

Mam nadzieję, że to przydatne, aby rozwiązać problem.

Podobny do tego, co stwierdził Muhammad Iqbal .. Byłem w VB.NET (może być też C #), gdzie projekt nie usunąć parę klucz-wartość z App.configktórą odniesione przez zmienną globalną do Sub Main()z Module Main. Dlatego wyjątek (i przerwa) występuje Module Mainprzed Sub Main(). Gdybym tylko miał punkt przerwania Dim, ale zwykle nie łamiemy zmiennych globalnych. Być może dobry powód, aby nie deklarować globałów odwołujących się do pliku App.config? Innymi słowy, to ...

W Nieznanym module wystąpił nieobsługiwany wyjątek typu „System.TypeInitializationException”. Inicjator typu dla „Namespace.Main” zgłosił wyjątek.

Spowodowane przez...

App.config

<connectionStrings>
    <!--<add name="ConnectionString1" connectionString="..." />-->

Moduł główny

Module Main
    Dim cnnString As String = ConfigurationManager.ConnectionStrings("ConnectionString1")  '<-- BREAK HERE (EXCEPTION)

    Sub Main()

        // main code

    End Main
End Module

W moim przypadku miałem klasę pomocnika, która była statyczna. W tej klasie była metoda inicjalizacji SqlCommand zależnej od zmiennych. Ponieważ było to wywoływane w kilku miejscach, przeniosłem je do klasy pomocnika i wywołałem w razie potrzeby, więc ta metoda była również statyczna. Teraz miałem właściwość globalną, która była ciągiem połączenia w Global.asax wskazującym na ciąg połączenia w web.config. Sporadycznie otrzymywałem komunikat „Inicjator typu dla„ Pomocnika ”zgłosił wyjątek”. Jeśli przeniosłem metodę z klasy Helper do klasy, w której była wywoływana ze wszystkich, było dobrze. Wewnętrzny wyjątek narzekał, że obiekt jest pusty (klasa Helper). Dodałem Używanie Pomocnika do Global.asax i nawet jeśli nie był używany przez Global.asax, to rozwiązało problem.

Moja odpowiedź dotyczy również sekcji Konfiguracja. Jeśli przypiszesz wartości z pliku Config w klasie statycznej C # lub Module.VB VB, ten błąd pojawi się w czasie wykonywania.

add key = „LogPath” wartość = „~ / Error_Log /”

Użycie ukośnika do przodu w Web.Config prowadzi również do tego błędu w czasie wykonywania. Właśnie rozwiązałem ten problem, umieszczając BackSlash

add key = „LogPath” wartość = „~ \ Błąd_log \”

Owinąłem linię, która ulegała awarii, w bloku try-catch, wydrukowałem wyjątek i zerwałem natychmiast po jego wydrukowaniu. Pokazane informacje o wyjątku zawierały ślad stosu, który wskazał mi plik i wiersz kodu powodujący wystąpienie błędu.

System.TypeInitializationException: The type initializer for 'Blah.blah.blah' threw an exception. 
---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Some.Faulty.Software..cctor() in C:\Projects\My.Faulty.File.cs:line 56
   --- End of inner exception stack trace ---
   at Blah.blah.blah(Blah.blah.blah)
   at TestApplication.Program.Main(String[] args) 
   in C:\Projects\Blah.blah.blah\Program.cs:line 29 Exception caught.

Jakoś wyjście z Visual Studio i ponowne otwarcie go rozwiązało dla mnie.

Klucze słownika powinny być unikalne!

W moim przypadku korzystałem ze Słownika i znalazłem w nim dwa przedmioty, które przypadkowo mają ten sam klucz.

Dictionary<string, string> myDictionary = new Dictionary<string, string>() {
            {"KEY1", "V1"},
            {"KEY1", "V2" },
            {"KEY3", "V3"},
        };

Warto zauważyć: miałem wiele projektów w swoim rozwiązaniu i zapomniałem dodać biblioteki referencji / bibliotek Nuget. Kiedy uruchomiłem metodę w klasie statycznej, która korzystała z danych bibliotek, zwrócił wspomniany wyjątek.