Operacja może zdestabilizować runtime?

Znalazłem ten wpis szukając własnego rozwiązania "operacja może zdestabilizować runtime". Chociaż powyższa porada dotycząca kowariancji / kontra-wariancji wygląda bardzo interesująco, w końcu odkryłem, że otrzymuję ten sam komunikat o błędzie, uruchamiając moje testy jednostkowe z włączonym pokryciem kodu i zestawem atrybutów allowpartialt Trustedcallers.

Usunięcie atrybutu AllowPartiallyTrustedCallers spowodowało, że moje testy działały poprawnie. mogę również wyłączyć pokrycie kodu, aby one uruchomić, ale to nie było akceptowalne rozwiązanie.

Miejmy nadzieję, że pomoże to komuś innemu, kto trafi na tę stronę, próbując znaleźć rozwiązanie tego problemu.

Tylko zgaduję, ale operator as może zwracać null - więc może mieć to związek z rzeczywistą implementacją kodu new SomeObject { ... }, ponieważ jest cukrem składniowym. Filtry return results.OfType<ISomeTable>(); oparte na typie, więc instrukcja return metody zwróci tylko ten typ (zapewniając bezpieczeństwo typu). Napotkałem podobny problem ze zwracaniem typów generycznych.

P. S. podoba mi się " operacja może zdestabilizować runtime."wyjątek. To prawie jak " możesz wysadzić internet" wyjątek.

Natknąłem się na ten błąd z podobnym kodem;

IEnumerable<Table> records = (from t in db.Tables
                              where t.Id.Equals(1)
                              select t).ToList();

Ten pozornie nieszkodliwy kod był częścią metody UserControl, która została wywołana ze strony. Nie ma problemu w środowisku programistycznym. NET4, jednak gdy strona była wstępnie skompilowana i wdrożona na serwerze na .NET3.5 dostałem ten błąd.

Podejrzewam, że ma to coś wspólnego z faktem, że kontrola była kompilowana do oddzielnej biblioteki DLL w połączeniu ze zmianami zabezpieczeń między frameworkami, jak opisano w this. Net security blog

Moje rozwiązanie: Uruchom witrynę live na .NET4

Czy nadal nie działa, jeśli to zmienisz:

select new SomeObject { ... } as ISomeTable;

Do tego:

select (ISomeTable) new SomeObject { ... };

?

Jeśli tak (jak widzę potwierdzasz), może ma to związek z faktem, że implementacja interfejsu może być klasą lub strukturą? Czy problem nadal pojawia się, jeśli rzucisz do klasy abstrakcyjnej, a nie interfejsu?

Odkryłem, że OfType ma pewne nieprzyjemne skutki uboczne podczas korzystania z linq do sql. Na przykład, części linq, które zostały wcześniej ocenione po uruchomieniu zapytania z db, zostały zamiast tego przetłumaczone na SQL. Nie powiodło się to, ponieważ te sekcje nie miały odpowiednika SQL. Skończyło się na zażywaniu .Zamiast tego obsada, która wydaje się również rozwiązywać problem.

W moim przypadku błędnie zadeklarowałem właściwość Storage w atrybucie kolumny klasy Linq2SQL

    [Column(Storage = "_Alias", DbType = "NVarChar(50)")]
    public string UserAlias

Miałem ten sam problem, ale z dziedziczeniem Zdefiniowałem klasę w assembly A i podklasę w Assembly B po dodaniu poniższego atrybutu do assembly A, problem rozwiązany:

[assembly: SecurityRules(SecurityRuleSet.Level1, SkipVerificationInFullTrust = true)]

Napotkałem ten błąd podczas korzystania z " Dynamic data access framework "Passive library . Źródłem błędu była linia 100 W DynamicDatabase.plik cs.

databaseDetectors = (databaseDetectors ?? Enumerable.Empty<DatabaseDetector>()).DefaultIfEmpty(new DatabaseDetector());

Zmieniłem linijkę kodu na:

databaseDetectors = (databaseDetectors ?? Enumerable.Empty<DatabaseDetector>()).DefaultIfEmpty(new DatabaseDetector()).OfType<IDatabaseDetector>();

Na marginesie, oryginał biblioteka działała dobrze na moim komputerze lokalnym i na VPS Rackspace, ale kiedy pchnąłem ten sam kod do współdzielonego środowiska hostingu (GoDaddy i witryny w chmurze Rackspace), zacząłem otrzymywać błąd "operacja może zdestabilizować runtime".

Domyślam się, że Linq do Sql może nie obsługiwać castingu przy tłumaczeniu na polecenie sql.