Sequence contains more than one element

Launching a new debugger instance from code in Visual Studio

This post was most recently updated on February 25th, 2019.

Reading Time: 2 minutes.

This post describes a quick solution to launching a new Visual Studio instance for debugging the code. There’s a lot of applications for this, but where I’ve found it exceptionally useful, has been in debugging the Entity Framework’s code-first migration’s (one of the ways for database initialization) Seed-method.

It is by default undebuggable, as when you are running Update-Database you can’t really use a -debug switch or anything, and there’s really no way to launch the debugger. Hence the best you can do is using -verbose to get more information.

However, if you actually want to see what is happening in the code, you CAN actually launch and attach the debugger to your code. Here’s the solution!

Solution: Launching the debugger programmatically

Okay – this is quick and dirty, but still pretty darn cool.

You can make your C# code launch a new Visual Studio instance to debug what you’re doing, by inserting the following line anywhere in your code:

System.Diagnostics.Debugger.Launch();

That alone is kind of dirty, and actually might end up causing recursive debugger launches – so you probably don’t want that! You’ll need a bit more code around the call, to make sure you only start debugging when it actually make sense.

Basically, you’ll want to check if you already have a debugger attached to your code, you don’t want to launch it again. You can access the info from System.Diagnostics.Debugger namespace, which has “IsAttached” property, that’ll be true if a debugger instance is already attached to your code.

So, in short we can check for any attached debuggers with System.Diagnostics.Debugger.IsAttached and just wrap a simple conditional block around our call to System.Diagnostics.Debugger.Launch(). This let’s us only attach a new debugger instance only when we don’t have one – and we’ll avoid recursive debugger attachments :)

Hence the following code:

if (System.Diagnostics.Debugger.IsAttached == false) {
  System.Diagnostics.Debugger.Launch();
}

This code will nicely fire open a new instance of Visual Studio and start debugging whatever’s at the function where you invoked the call. It’s kind of slow – it’ll actually open up a new instance of Visual Studio, and as we all know, that tends to take a while!

After Visual Studio opens up, it should make it possible for you to debug line by line, starting from where you launched it. You can also set breakpoints as you wish, and that should work as usual!

References

Got this awesome tip from Stack Overflow.

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.
mm

2
Leave a Reply

avatar
5000
2 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
0 Comment authors
Tip: The best way to debug the Seed-method in EF's Code-first migrations in Configuration.cs when running Update-Database - #SharePointProblems / Koskila.netEasiest way to debug Seed method in EF Code-first migrations in Configuration.cs when running Update-Database - #SharePointProblems Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
trackback

[…] bit more information out of the process, without attaching the debugger (there’s another blog post for […]

trackback

[…] bit more information out of the process, without attaching the debugger (there’s another blog post for […]