It takes an additional ~3 seconds for the debugger to attach

[Meai1]

My issue here is that this basically increases the edit/compile dev cycle by another 3 useless seconds. I really think that this should be fixable, I mean in Visual Studio it starts up much much faster too..
Just to be 100% clear: This is after the compilation is done and then the rest of the work is only IDE related debugger attachment, that is what this issue is about.

Environment data

dotnet --info output:
[pc@localhost ~]$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
Version: 1.0.0-preview2-1-003177
Commit SHA-1 hash: a2df9c2576

Runtime Environment:
OS Name: centos
OS Version: 7
OS Platform: Linux
RID: centos.7-x64

VS Code version:
C# Extension version: 1.5.2

Maybe it has something to do with these messages:

---

You may only use the C# Extension for Visual Studio Code with Visual Studio
Code, Visual Studio or Xamarin Studio software to help you develop and test your
applications.

Loaded '/opt/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Private.CoreLib.ni.dll'. Cannot find or open the symbol file.
Loaded '/home/pc/Apps/dotnet-mytest/bin/Debug/netcoreapp1.0/dotnet-mytest.dll'. Symbols loaded.
Loaded '/opt/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Runtime.dll'. Cannot find or open the symbol file.
(many more such dlls, cant copy paste this easily)

[gregg-miskelly]

@Meai1 we have work in flight to switch to pre-native-compiled (ngen'ed) versions of a number of the managed dlls, in the debugger which will have a big impact on startup perf. We will let you know when its done so you can tell us if it feels fast enough or not.

[DustinCampbell]

Is this still an issue or did the NGEN'ing fix it?

[gregg-miskelly]

@Meai1 have you had a chance to try the 1.6.x version of the C# extension? If so, do you feel like it is still too sluggish?

[Meai1]

nah it's good now

[DustinCampbell]

Great! Thanks!