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=3.5.0.0 ...

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:

config.Types.Register(Assembly.GetExecutingAssembly());

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");
    config.Types.Register(Assembly.GetExecutingAssembly());
    domain = Domain.Build(config);

    using (Session.Open(domain))
        PopulateData();

    return domain;
}

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

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:

[TableMapping("Links")]
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.