Visual Studio, Unable to attach debugger, no errors

• If there is a better place to post this, please advise
• Using Unity 2018.3.0f2
• Using Visual Studio 15.9.4 (2017, latest)
• I see the attach to unity option
• When I attach, It builds (no errors), but it does not 'lock' for break point handling
• No errors in console or output or errors
• How can I debug this ?

 

I've just updated to 2018.3, and I've had no issues hitting breakpoints after doing so. However, what you're describing does happen to me from time to time. In most cases, what "fixes" it for me is to close Unity, delete the Library/ScriptAssemblies directory in your project, and then reopen Unity.

 

@nventimiglia did you find a way to solve this ?
It happens to us on 2018.0.3f2, in fact the debugger can attach but it takes something like 3-5 minutes before reaching (displaying) the breakpoint.

Maybe @jbevain could have a solution or some hint on this ?

 

So my current investigation in our team of 6 dev @jbevain :

================= Fast configuration recap ================
- We have Windows 10.
- We use Visual Studio 2017 but on multiple version indicates in front of each dev right below with parenthesis.
- We use Unity 2018.3.0f2 except for an older project where we stay in 2017.4.X (X currently 16).

- On the projects with 2018.3.0f2 we use the asmdef
- On the older project with Unity 2017.4.X we don't use them.
====================================================​

Me (15.9.4) :
Often use them in specific case with a lot of breakpoints but remove them doesn't change linking time.
Before removing .vs hidden folder it tooks something like 3-5 minutes to reach the breakpoint not to attach.
Attach time is fine.
Delete .vs folder solved the 1st breakpoint reaching issue.

Dev 1 (15.7.5) :
Often use VS with breakpoints, works on the same project than me, linking time rarely exceeds 1 min when it goes wrong. No others issue noticed.

Dev 2 (15.9.4 & 15.9.5):
Often use them in specific case with a lot of breakpoints but remove them doesn't change linking time.
Before removing .vs hidden folder he stops using it due to huge amount of time.
Delete .vs folder solved the 1st breakpoint reaching issue.

Dev 3 :
Visual Current version (15.7.5) :
Project 1 (Unity 2018) => Visual Studio generation issue with assemblies whereas it's ok within Unity.
Project 2 (Unity 2018) => Could take something like a minute to attach/or debug but nothing montrous
Project 3 (Unity 2017) => No particular issue

Visual Updated Version (15.9.5) :
Project 1 (Unity 2018) : (With .vs cleaning) Visual Studio generation issue is gone and breakpoint are ok.
Project 2 (Unity 2018) : VS update without cleaning .vs and attachment takes less than 10sec and breakpoint something like one second.
Project 3 : VS update without cleaning .vs folder and still fine.

Dev 4 :
Visual Current Version (15.8.7) :
Often use them in specific case with a lot of breakpoints but remove them doesn't change linking time. Huge amount of time to reach the first breakpoint but seems ok to attach.
Delete .vs folder solved the attachment issue and the breakpoint reaching issue.

Visual Updated Version (15.9.5) :
Attachment freeze totally unity for 1min maybe more cause he stops the VS attachment and unity continued instantly after this.
Delete .vs folder solved the 1st breakpoint reaching issue.

Dev 5 :
I don't ask him for now.

One thing that I can note with all of that stuff is :
With the report from our dev 1 & 3 it could allow you to maybe find something in the update after the 15.7.5 that could trigger this issue.

After 15.7.5 update (I don't know which update) there is some difficulty with VS & Unity with debugger linking and 1st breakpoint reaching during each debug process.

**Assumption start**
Maybe due to some change between vs version and some difference in the files saved in this folder ?
** Assumption end **

P.S :
Concerning the project 2 from our dev 3 without .vs folder deletion. What he gonna do, is to use Unity 2018 + VS in the current state and see if with time the problem starts to appear or not.

 

Seeing same problem. Been attaching all day just fine then all of a sudden my breakpoints never turn into red circles...

 

@jbevain a little ping just to know if you have some information on that point ?
My trick consisting to remove .vs folder is still useful but it's a pain to do this everytime it starts to be sloooow. And I lose my breakpoint each time I have to do this

 

I'm seeing the same issue in Unity 2019.3.0A8. Specifically, Visual Studio opens, but shows 'Start' instead of 'Attach to Unity', making debugging impossible.

• This same install of Visual Studio can attach and debug fine in Unity other projects.
• Settings are correct in Unity preferences (attach/debugger selection).
• Visual Studio (2019 Preview) settings are correct - Unity plugin and Unity enabled in options.

Creating a new project in:

• 2019.3.0a8 - Start button, no debugging.
• 2019.2.0b6 - Start button, no debugging.
• 2019.1.8f1 - Attach to unity button, works!

I'm aware that the .proj file has a projectType GUID that flags it as a Unity project, this is used to let VS would know to enable Unity behaviors for a project. Did this method change with 2019.2? because the .proj files are missing this info, Unity is no longer adding it to the projects it's generating.

If I paste the appropriate section into my project file for 2019.3 then the type icon changes and the 'Attach to Unity' button appears and I am able to debug and everything works fine. Except obviously Unity then re-generates the .proj file after any changes and overwrites it, reverting back to broken.

Code (CSharp):

1.   </PropertyGroup>
2.     <PropertyGroup>
3.     <ProjectTypeGuids>{E097FAD1-6243-4DAD-9C02-E9B9EFC3FFC1};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
4.     <UnityProjectGenerator>Unity/VSTU</UnityProjectGenerator>
5.     <UnityProjectType>Game:1</UnityProjectType>
6.     <UnityBuildTarget>StandaloneWindows64:19</UnityBuildTarget>
7.     <UnityVersion>2019.1.0b8</UnityVersion>
8.   </PropertyGroup>

E097FAD1-6243-4DAD-9C02-E9B9EFC3FFC1 (means C# Project)
FAE04EC0-301F-11D3-BF4B-00C04F79EFBC (means Unity Project)


This is really annoying. Any ideas?


EDIT: Okay so a workaround is that i can go to Debug>Attach Unity Debugger :S