Operation could destabilize the runtime?

Question

I\'m having a little bit of trouble understanding what the problem is here. I have a bit of code that pulls records from a database using LINQ and puts them into an object

Answer 1

I ran into this error while using the "Dynamic data access framework" Passive library. The source of the error was line 100 in the DynamicDatabase.cs file.

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

I changed that line of code to:

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

Doing so resolved the problem. I went ahead and forked the project and submitted the change to the original author.

Thank you, Jason Baker, for pointing out the solution in your original question.

On a side note, the original library ran fine on my local machine and on a Rackspace VPS, but when I pushed the same code to a shared hosting environment (GoDaddy and Rackspace's Cloud Sites), I began getting the "Operation could destabilize the runtime" error.

Answer 2

In my case i had wrongly declared the Storage property in the Column attribute of a Linq2SQL class

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

Answer 3

I came across this error with similar code;

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

This seemingly harmless code was part of a UserControl method which was called from a Page. No problem in a .NET4 development environment, however, when the site was PreCompiled and deployed to the server on .NET3.5 I got this error.

I suspect this has something to do with the fact that the control was being compiled into a separate DLL combined with the security changes between the frameworks as described in this .NET security blog

My solution: run the live site on .NET4

Answer 4

I found that OfType had some nasty side effects when using linq to sql. For example, parts of the linq that were previously evaluated after the query was run against the db were instead translated to SQL. This failed as those sections had no SQL equivalent. I ended up using .Cast instead which seems to solve the problem as well.

Answer 5

Just a guess, but the as operator may return a null - so it may have to do with the actual implementation of the new SomeObject { ... } code, since it's syntactic sugar. The return results.OfType<ISomeTable>(); filters based on type, so your method's return statement will only return that type (ensuring type safety). I've run into a similar issue with returning generic types.

P.S. I love the "Operation could destabilize the runtime." exception. That's almost like the "You might blow up the internet" exception.

Answer 6

Does it still fail if you change this:

select new SomeObject { ... } as ISomeTable;

to this:

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

?

If so (as I see you've confirmed), perhaps this has to do with the fact that an interface implementation could be either a class or a struct? Does the problem still appear if you cast to an abstract class rather than an interface?