Title says it all.

I start a new DataObjects web project. Add the sqlserver provider as my default. Create a VERY simple entity that reflects a table in the database.

Build throws an exception complaining: System.Security.VerificationException: {"Operation could destabilize the runtime."}

The machine this is on is a new install of Windows 7 64 bit. This is running in VS2010, or rather not running. Using the latest available package from xtensive.

asked Aug 31 '10 at 11:24

Smhoff's gravatar image


edited Aug 31 '10 at 15:23

Alex%20Yakunin's gravatar image

Alex Yakunin

Latest = v4.3.5? Important, because it was just published, although this isn't officially announced.

(Aug 31 '10 at 15:26) Alex Yakunin Alex%20Yakunin's gravatar image

One Answer:

I just studied your sample, and identified a set of issues. I my case they were different - i.e. I didn't seen verification exception, but I suspect, it could occur because you were trying to run .NET 4.0 application in .NET 2.0 application pool.

Anyway, let's review what I found:

1. web.config there is pretty strange

It references a set of .NET 3.5 assemblies, although you use version of DO for .NET 4. Moreover, target framework inside .csproj is set to .NET 4 as well.

I tried to install this application both to "ASP.NET v4.0" and "ASP.NET 4.0 Classic" application pools, and in both cases my IIS 7 was reporting "HTTP 500.19 - Internal Server Error" pointing to <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version= ...

I compared your web.config it with web.config from our ASP.NET sample, and found lots of differences. So finally I decided to simply replace it by our own, and slightly modify it.

This helped almost instantly.

2. the same is about .csproj.

It seems it's VS2008 project (<ProductVersion>8.0.30703</ProductVersion>); moreover, it reverences a set of .NET 3.5 assemblies as well (without any necessity for this).

I fixed this by comparing it with .csproj from ASP.NET sample as well.

3. There were few minor bugs in code

You didn't register any types in DomainConfiguration, so your query couldn't run. So I added this code to DomainBuilder.cs:


Also, you didn't create any persistent type, so Query.All<Link>().Single() was throwing exception. This was fixed by making PopulateData method really work:

public static Domain Build()
    var config = DomainConfiguration.Load("Default");
    domain = Domain.Build(config);

    using (Session.Open(domain))

    return domain;

public static void PopulateData()
    using (var tx = Transaction.Open())
        using (Validation.Disable()) 
            var link = new Link() 
                LinkDescription = "Hello world!"

After all these changes the application began to show "Hello world!" message.

Finally, I made 2 cosmetic improvements:

a) I renamed your Links type to Link and applying [TableMapping] attribute to it:

public class Link : Entity

b) I changed DomainBuilder so that base Domain configuration is read from web.config (this was shown above - initial configuration is populated via DomainCobfiguration.Load method).

You can download version of your application with my modifications to study the changes. I recommend you to compare it with your original code using a tool like Beyond Compare.

In addition, I added Install folder there with Install.bat file. it adds "DOTesting" application to your IIS 7 and properly configures it. Uninstall.bat does the opposite.

So to test everything quickly, download the archive, extract it somewhere, run Install.bat and navigate to http://localhost/DOTesting.

Remember that:

  • you should modify connection string to your own one.
  • ASP.NET Development Server in VS.NET 2010 doesn't fully support IIS 7 configuration. In particular, it doesn't support <modules> section there. So you can run this application only inside IIS 7. I already made necessary changes to .csproj (I also noticed we should do the same with our samples).

Good luck with testing DO further!

Original answer:

Could you send us the project to support@(our web site).com? That's the only easy way to check/reproduce this.

This is only possible, if either our aspects or PostSharp inject unverifiable MSIL code. I remember there were some issues like this when we were migrating to PostSharp 2.0 - simply because our weaver was unstable. But currently this should never happen.

answered Aug 31 '10 at 15:13

Alex%20Yakunin's gravatar image

Alex Yakunin

edited Sep 02 '10 at 18:28

I can certainly send you the project. The only thing you would need to change is to point it at a sqlserver instance. Check your mail it should be there shortly. Thanks!

(Sep 01 '10 at 07:35) Smhoff Smhoff's gravatar image

I studies your sample. See the answer above - I just edited it.

(Sep 02 '10 at 18:23) Alex Yakunin Alex%20Yakunin's gravatar image

Update: I already understood how such web project could appear: you've built an application using our Web Application template!

It seems we've occasionally merged the changes made to it in .NET 3.5 branch to the default (.NET 4.0) branch. This also means we'll update the latest installer today.

I apologize for this issue. Thank you once more for contacting us.

(Sep 02 '10 at 18:52) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA