WARNING: this might leave your computer vulnerable. You're doing this under your own risk.

If you're in this situation, take a look at this article: https://gallery.technet.microsoft.com/Restart-Computer-with-707ae728.

Copy the powershell script from there into a file called Restart-ComputerWithBitlocker.ps1. To run, open Powershell as an Administrator and execute:

PS> . .\Restart-ComputerWithBitlocker.ps1; Restart-ComputerWithBitlocker

If you prefer to have a CMD file, create one and put these contents inside:

@echo off
powershell -command "& { . %~dp0\Restart-ComputerWithBitlocker.ps1; Restart-ComputerWithBitlocker }"

Again, you'll have to execute as an Administrator.

Note that this is not supported by Microsoft. Also, note that if you chose to execute this you're clearing Microsoft and myself from any issues that might derive from it, including security-related issues. Please, always ensure you understand each and every step of what you're doing before executing any code taken from the internet.

• NP Profiler
• Make sure to select the Store App version of NP
• https://www.microsoft.com/en-us/download/details.aspx?id=35370
• WinDbg
• If you have the Windows Developer Kit, you already have it
• https://msdn.microsoft.com/en-us/windows/hardware/hh852365
• SOSEX
• This is an extension to analyze managed stacks in WinDbg
• https://www.stevestechspot.com/

Start the NP profiler and select your app. Select "Run under Debugger (without the profiler)" and select WinDbg from the Profiler Options.

Click on Start Profiling. WinDbg will start up and immediately kick off execution of your application.

Immediately, load SOSEX by executing:

.load [path\to\sosex\sosex]

Set WinDbg to break on CLR exceptions by executing:

sxe clr

Continue execution of your app under WinDbg until you hit the first chance exception. Once there, you can list the stack trace by executing:

kP

Or list the managed stack trace (with access to IL) by executing:

!mk

This should tell you where your application is crashing. The first chance exception will typically give you an address in memory of the instruction that failed, and if it's in managed code, it'll tell you the IL+number where it happened. That number is the number of IL instructions into the method where it failed. You can list the IL for the method by clicking on the IP of the function, or typing !muf [memory address]

So for example, if the exception tells you that it's thrown from IL+001e you can go to the method that threw and see what is in that space:

In this example, the exception was thrown when we called Window.get_Content.

https://mvpstream.azurewebsites.net/

Highly recommended resource for Spanish-speaking developers. Make sure you follow @mvpstreams on twitter too!

You can see the entire Entity Framework Performance Considerations whitepaper here: https://aka.ms/efperf

Please leave questions, comments, and requests for improvement in the comments. Thank you!

David.

Enjoy!

Whenever EF is used in a multithreaded scenario, or in any application that resembles a server system, make sure to enable server garbage collection. This is done via a simple setting in your application config file:

<?xmlversion="1.0" encoding="utf-8" ?>

<configuration>

        <runtime>

               <gcServer enabled="true" />

        </runtime>

</configuration>

This should decrease your thread contention and increase your throughput by up to 30% in CPU saturated scenarios.

1) The good and hard way: refactor your code to be more compact and simplified. This will help the JIT'er produce code faster and possibly better optimized.

2) The easy way: NGEN your application and its dependencies.

NGEN will compile your assembly and load it with zero JIT cost. This proves to be tremendously useful in cold-startup scenarios.

     public class Blog

    {

        public int BlogId { get; set; }

        public string Name { get; set; }

        public virtual ICollection<Post> Posts { get; set; }

    }

    public class Post

    {

        public int PostId { get; set; }

        [MaxLength(200)]

        public string Title { get; set; }

        public int LikeCount { get; set; }

        public int BlogId { get; set; }

        public Blog Blog { get; set; }

    }

    public class BlogContext : DbContext

    {

        public DbSet<Blog> Blogs { get; set; }

        public DbSet<Post> Posts { get; set; }

    }

 In terms of usability it's a great way to go since the code is self-explanatory and can be highly customized via the Fluent API. Now, you might be asking yourself: what happened with the EDMX file? Well, you don’t really see it but it still exists.

The way Entity Framework Code First works is by analyzing your assemblies for all the types related to your model and enumerating into a set of “discovered types”. Once EF knows about these types, it explores them looking for special attributes such as [Key], [MaxLength] and [Index] to know more about the model. Finally, it applies a set of conventions that allow it to discover information that’s not explicitly set. One such convention is the discovery of keys by which field PostId is discovered as the key to the Post entity. There’s a number of these conventions and it’s important that you understand them before using Code First.

The resulting fully-loaded model description is stored in memory using the EDM format. Effectively, Code First reverse-engineers an EDMX out of the POCOs, attributes and fluent API calls. From here on, Entity Framework doesn’t care whether you created the model Code First or Model First, it behaves the same. It goes on and generates the views, validates the model and sets up all the metadata to be ready to serve its purpose.

As you might imagine the process of reverse engineering the EDMX out of the Code First model is costly. It’s only paid for once on the startup of your first context, but it may represent a performance annoyance for your application. There’s a way to speed your start up though: use an EDMX in your project.

For this, you’ll want to obtain the EDMX data from your Code First context by calling:

EdmxWriter.WriteEdmx(context, new XmlTextWriter(new StreamWriter("MyModel.edmx")));

Call it in your context instance and you’ll get an EDMX file with all the data you require. Add the EDMX to your project and modify your connection string accordingly to make use of the EDMX data.

Large models will benefit the most. I’ve noticed reductions in the hundreds of milliseconds just for the EDMX generation part of the code.

To this effect, I've found that it's very easy to wrap an IQueryable around a LINQ provider that simply defers execution of the queries to the instance it wraps. The instance can then be mocked in our tests and we can continue development without this dependency. Such a wrapper provider looks much like this code.

Code:

    public class WrapperProvider : IQueryProvider
    {
        private readonly IQueryable _query;

        public WrapperProvider(IQueryable query)
        {
            _query = query;
        }

        public IQueryable<TElement> CreateQuery<TElement>(Expression expression)
        {
            return new WrapperContext<TElement>(this, expression);
        }

        public IQueryable CreateQuery(Expression expression)
        {
            return new WrapperContext(this, expression);
        }

        public TResult Execute<TResult>(Expression expression)
        {
            var newExpression = new ExpressionTreeModifier(_query).Accept(expression);

            if ((typeof(TResult).Name.StartsWith("IEnumerable")))
            {
                return (TResult)_query.Provider.CreateQuery(newExpression);
            }
            
            return (TResult)_query.Provider.Execute(newExpression);
        }

        public object Execute(Expression expression)
        {
            var newExpression = new ExpressionTreeModifier(_query).Accept(expression);
            return _query.Provider.Execute(newExpression);
        }
    }

    internal class ExpressionTreeModifier : ExpressionVisitor
    {
        private readonly IQueryable _query;

        internal ExpressionTreeModifier(IQueryable query)
        {
            _query = query;
        }

        protected override Expression VisitConstant(ConstantExpression c)
        {
            var wrapperType = typeof (WrapperContext);
            for (var iteratorType = c.Type; iteratorType != null; iteratorType = iteratorType.BaseType)
            {
                if (iteratorType == wrapperType)
                {
                    return Expression.Constant(_query);
                }
            }
            return c;
        }

        internal Expression Accept(Expression expression)
        {
            return Visit(expression);
        }
    }

    public class WrapperContext : IQueryable
    {
        public WrapperContext(IQueryable query)
        {
            Expression = Expression.Constant(this);
            Provider = new WrapperProvider(query);
        }

        internal WrapperContext(IQueryProvider provider, Expression expression)
        {
            Expression = expression;
            Provider = provider;
        }

        public IEnumerator GetEnumerator()
        {
            return Provider.Execute<IEnumerable>(Expression).GetEnumerator();
        }

        public Expression Expression { get; private set; }
        public Type ElementType { get; private set; }
        public IQueryProvider Provider { get; private set; }
    }

    public class WrapperContext<T> : WrapperContext, IQueryable<T>
    {
        public WrapperContext(IQueryable<T> query)
            : base(query)
        {
        }

        internal WrapperContext(IQueryProvider provider, Expression expression)
            : base(provider, expression)
        {
        }

        public new IEnumerator<T> GetEnumerator()
        {
            return Provider.Execute<IEnumerable<T>>(Expression).GetEnumerator();
        }
    }

In our actual code we may choose to do things like Assert.Equals(new WrapperContext<Customer>(context.Customers).Where(c => c.CustomerID == 1).Count(), 1), knowing that the execution will be deferred to whatever implementation of IQueryable the wrapper contains.

David.

LocalDb

  <entityFramework>

    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">

      <parameters>

        <parameter value="v11.0" />

      </parameters>

    </defaultConnectionFactory>

  </entityFramework>

Now, replace that portion of the configuration to make use of Sql Server instead of LocalDb.

Sql Server

  <entityFramework>

    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">

      <parameters>

        <parameter value="Data Source=.; Integrated Security=True; MultipleActiveResultSets=True" />

      </parameters>

    </defaultConnectionFactory>

  </entityFramework>

You only need to change the configuration to match your appropriate connection string.

David.