Bug Visual Studio integration is pretty busted

@Crayz @castor76

Sorry for the confusion and annoying issue. If any dialog is open in VS, the communication between the Tools for Unity and the Unity Editor is blocked - resulting in a new instance of VS opening because the Unity Editor sees no comm with VS and launches a new one.

We've done a lot over the years to improve the auto-reloading to avoid those Reload dialogs as much as possible. That being said, it would be great to get some details on the versions of VS and Unity you're using along with any details about what you were doing when that dialog appeared in VS.

 

Unity 2021.1.0a7
Visual Studio 16.7.2
Visual Studio Editor Package 2.0.5

Assembly definitions seem to be the culprit. The reload solutions dialog will appear when an assembly definition is created, deleted, and when a script is created or removed from an assembly definition. Modifying a script does not cause it.

2020-12-04_12-02-32.mp4 (streamable.com)

 

@Crayz

Thanks! I was able reproduce this and I filed a bug for us to look into.

 

tx

 

How about generating a cleaner csproj using sdk style project format?

https://docs.microsoft.com/es-es/nuget/resources/check-project-format#check-the-project-format

it's been around like 3 years? And Unity it's still using the old verbose format.

With sdk style format I think the reloads occur on background. At least it's my experience when I started developing .net core projects some years ago.

 

We are working on this already.

 

I read in another forum post, almost 30 seconds are spend in

SyntaxTree.VisualStudio.Unity.Bridge

when deleting a file that is included in the VS Solution. Any idea if this is related to csproj generation too?

 

@Peter77

Thanks for the link to the post. I'll reply over there about that performance concern.

 

@John_MSFT

Hi there, i am experiencing the same issues as mentioned on here - yesterday, opening a script from inside Unity worked fine, today, the link is broken. I already had this problem a couple of times, and there seems to be no solution for it.
Would you agree to look into that with me?
I am using Visual Studio 2019 Professional 16.8.2,
Unity 2019.4.4f1

 

@John_MSFT

Hey,
I have run into the problem that my C# Scripts won´t open and until now I wasn´t able to fix that problem. I´ve tried diffrent approches. Like Go to Assets → Open C# Projects. Or Edit → Preferences → Regenerate project files. Non of these fixed it.
Is there any solution for that?
Below are my Versions of Visual Studio and Unity.

Visual Studio Community 2019
16.8.2
Unity 2020.2.0b5

 

@CST-IT @AndreSeidel

Thanks for commenting. I'll send each of you a message to troubleshoot.

 

@John_MSFT Thanks for being so active in the forums - much appreciated. Without hijacking the 2020.2 beta thread too much I just wanted to chime in and say that on Mac it feels like every minor update of Unity, VSCode, VSCode Unity package, OmniSharp extension for VSCode, system Mono installation, or Visual Studio for Mac seems to break intellisense and debugging at every opportunity.

I am aware from your various posts that VSCode is not officially supported (I wish it was, it's been our primary editor for years) but Visual Studio for Mac seems to suffer in similar ways at times. Keeping the development tools working feels like a constant juggle and like somewhat of arms race for us. Broadly, are your product development teams experiencing issues like this, or is this more likely a Mac or site-specific issue?

 

@greg-harding

Thanks for the kind words. To your question, this is not something we are hearing broadly so I am surprised to hear it. I will send you a message to follow up.

With regards to VS Code and official support - this is something I am actively researching and looking to speak to developers about. For others that stumble on this post, please send me a message on here if you're willing to chat with me about your Unity experience with VS Code to help us improve the experience.

 

Perhaps an impactful low-hanging fruit improvement for VS Code experience with Unity could be support for DiagnosticSuppressor. Would be nice not to having to deal with false warnings regarding MonoBehaviour messages and [SerializeField] fields.

https://github.com/OmniSharp/omnisharp-roslyn/issues/1711

 

Cheers, John - I will reply to your PM. Thanks for your support!

 

Here is a list of issues i am getting:

If i create editor scripts they go into Csharp-Editor assembly and for what ever reason I lose all references to any thing outside of this assembly such as the object that the editor relates to for example. Even though it compiles perfectly fine in unity so its an intellisense issue.

Unity has Assembly-Csharp.Player and Assembly-CSharp, and for some reason scripts just seem to randomly choose which one to go into - for no known reason. I have some in the Player assembly and some in the Csharp assembly and theres no logical reason why this is happening to me. Or why both suddenly seem to exist when they didn't a year ago.

Second issue i am having, when i double click a console log to open the script to see the line of the error, it some times but not always opens another instance of visual studio, same if i double click a C# file in the asset folder to open it in order to edit it, another VS will open - drives me mad.

Some times the intellisense fails entirely across the whole project and nothing will link to anything and I end up with like 1000+ errors. (But in unity the console log shows no errors since the code is perfectly valid).

Most of problems are fixed by either (though i should not have to keep doing this every day):

1) restarting VS
2) clearing project cache files in unity so it rebuilds them.

Just today i've had to do it 4 times - and its now happening a 5th time which let me to google and find this thread so i can post about it.

I never used to have to this at all in the 2017 version of VS or even a mere year ago.

Version info:
Unity version 2020.2.5
Microsoft Visual Studio Community 2019 Version 16.8.4

 

@PixelizedPlayer

Thanks for taking the time to share this. It will help if you use the Help > Submit Feedback > Report a Problem menu in Visual Studio to document this. That will create an issue publicly that we can track and update status for you to see. Otherwise, these types of things will get lost in the forums.

While I'm here though, let me address what you mentioned:

Unity's compilation pipeline determines what gets put into these generated projects. You can control project generation more if you use .asmdef for your code and specify which targets the code is for. Also, there is an option in the Unity Editor > Preferences > External Tools to generate Player projects which you might have checked. If you believe there is something else going on please do report it as an issue so we can investigate.

First thing to check is that you have the latest 2.0.7 version of the Visual Studio Editor package installed. Unity Editor > Windows > Package Manager. If Visual Studio has a modal dialog open, Unity will not be able to communicate with it and a new instance will open. I mention this because it's a known limitation when something is done outside of Visual Studio that creates a "Reload solution" popup. If you notice that in the original instance of VS, please report the problem and the scenario that created the dialog so we can investigate. If you're not experiencing that dialog, or one like it, it's worth reporting as a possible bug.

I am not sure about this issue. Do you notice any common pattern of behavior that leads up to the problem? Working with .asmdefs, local packages, etc?

 

I managed to reproduce one of the issues (the one where it opens a new instance of visual studio).

It happens when unity is recompiling everything, for example if you create a new script and double click it before unity has done some kinda recompile it will launch a new instance of visual studio. I do not know if thats unity's fault or VS.

First thing to check is that you have the latest 2.0.7 version of the Visual Studio Editor package installed.

Ah that was not up to date so hopefully that might help ( seems unity does not notify of new updates or have an auto update feature for packages!).

If the problem still persists, i will file a bug report to VS regarding the intellisense failing all the time.

 

I've not been able to reproduce this yet. If you do continue noticing that, please report the problem and any details you can share on how to reproduce it. Thank you!

 

I have filed a report just now regarding Unity3D and intellisense breaking (that was my second issue I have been facing). I provided a screenshot to show its failing although i have no clue how to reproduce that particular bug.





Hopefully you're able to find the feedback bug report (its for VS 2019) but as you can see from this screenshot it just fails across the whole project all the time for no reason.

I titled it: Intellisense breaks for Unity3D

Encase you are able to take a look by searching up the report title.

 

@John_MSFT My apologies if this has already been answered. People on this thread seems to have mixed issues here, bless you for having the patience to sort through it. Each time I install a new version of Unity, I have to 'Regenerate project files'. Is this expected behavior now? It seems to have started happening around Unity 2020+.



To be clear, I'm not entirely sure if this is a Unity issue, or an issue with the VSIX toolset. Regenerating the project files always solves it. Other theory is a potential issue between ReSharper and VSTU.

 

No, that is not expected. We expect this to be done automatically for you. When I try to reproduce it by opening a project from 2020.1.x and than in 2020.2.x, I don't experience any issues. Maybe I am missing a nuance on exactly how you do an upgrade or open files/solutions.

It would be best to use the Help > Submit Feedback > Report a Problem menu in VS to document the issue and the steps you typically perform to encounter this problem. i.e. are you using Assets > Open C# Project, double-clicking C# files, double-clicking a component from the Inspector, of using VS to open a solution. Are you deleting/uninstalling the previous version of Unity after updating?

 

It just happened to me too, when I upgraded the latest 2020 version. Had to manually regenerate the files and then restart VS a few times.
It doesn't always happen, just sometimes.

 

What version of Unity where you using before the upgrade? What was the issue you experienced after updating that led you to regenerate the project files?

 

2020.2.7 to 2020.3.0, so the smallest upgrade possible. It did not happen on previous upgrades.
VS did not recognize Unity functions or even my own anymore. Everything from my assemblies had red underscores.

 

Honestly, both these things are insanely annoying.

* Visual studio is constantly opening new instances when I double click a file, even though the sln is already open, which just eats like 20s for no reason
* Constantly and totally locking up with "Do you want to reload assemblies", which I click Yes on 100% of the time. A "Remember my choice" checkbox would be half a decade overdue here!
* Now I have an issue where none of my packages namespaces are resolving, despite "regenerating project files" multiple times.

It has to be a serious question, does anyone on the Unity team use Visual Studio in production on a day to day basis? I can't see anyone being ok with fighting their tooling like this. It used to work so nicely :'(

 

@shawnblais

I'm sorry you're experiencing so many issues - it's not something we see widespread so I'd love to work with you and find out more so we can fix it.

Feel free to message me on these forums directly, or file a bug using Visual Studio > Help > Submit Feedback > Report a Problem.

 

Thanks John! That good to hear that its not widespread, just a bummer for me I guess!

I could send you our entire project and see if you can reproduce, would that work?

Also, I've read that VS 2017 can be lessy buggy than 2019 (when it comes to Unity integration), is that the case to your knowledge?

 

Still having these problems. I've built a habit around bad ux that causes me to check Visual Studio every time before I double click a script in Unity. But sometimes it still gets me.

every time VS opens a new instance: (┛◉Д◉)┛彡┻━┻

 

There is one specific thing that would be amazing, how can we get rid of that "Reload Assemblies" modal dialog? Is there some dark magic somewhere that can just tell this thing "Yes, always reload assemblies"? I've searched the entire internet on this issue several times over the years.

I'm thinking these things are related. When you move some folders around in Unity, VS code locks up with this silly dialog (dialog is fine, but why . Then you try and open a script, and Unity can't communicate with VS, so it opens a new instance? Just shooting in the dark, but this feels like it lines up with my experience.

Fwiw, I am also seeing this bug each time I double-click, though the file does open:

Exception thrown while invoking [OnOpenAssetAttribute] method 'SyntaxTree.VisualStudio.Unity.GeneratedAssetOpener:OpenScript (int,int)' : TypeLoadException: Could not resolve type with token 01000004 (from typeref, class/assembly SyntaxTree.VisualStudio.Unity.Bridge.ScriptAssetOpener, SyntaxTree.VisualStudio.Unity.Bridge, Version=3.5.0.3, Culture=neutral, PublicKeyToken=null)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr, Boolean&)
​

As you can see here, it's just not seeing classes it should:

 

I did a bit more testing (and sent @John_MSFT a scene he can run) and the multiple instances issue is related to moving files. You can reproduce the multiple-opening issue easily:
1. In unity, drag some .cs file to another folder, ie move /scripts/foo.cs to /scripts/bar/foo.cs
2. VS will lockup with a blocking modal dialog
3. Without responding to dialog, dbl click a file in Unity

VS will kick open a new version. Now you have 1 version churning for 20s trying to open, and the other sitting there, wasting time, asking you if you want to reload, which of course you do, which also takes 10s.

It seems when creating/deleting files this is not an issue, as VS correctly reloads itself in the background. We just need that same auto-load mechanism that happens on Create, to happen on Move.

 

To add (this was mentioned earlier in thread) anything to do with assembly definitions also causes the reload dialog to appear.

 

This is a known limitation. If there are any modal dialogs open in Visual Studio, the communication between Unity and VS is blocked. So, when you double-click a file it's believed that there is no existing VS because of that block and so a new instance opens.

That being said, we may have a bug here to investigate. Can you share more details so we can investigate? Use the Help > Submit Feedback > Report a Problem menu in VS and I can help investigate.

This is a good example of a scenario to document. If I follow the steps you outlined in my simple project, it does not reproduce the issue. I will try with the project you sent me. Thanks!

 

It seems like it's a known issue that should be very easy to fix. Just always reload assemblies when they change and then there is no modal.

1. Can we not just get a checkbox that says "Remember my setting?"
2. Or some setting that just tells it to always auto-reload?
3. Why does the dialog need to be blocking at all?

I can't actually think of a use case where a Unity developer would not want to reload these. Why is VSCode optimizing for the .01% use case here?

There is a setting for this, it just doesn't work right.

It seems to be a bug in this setting here:


"Unless there are unsaved changes" is not the behavior I'm seeing. My projects don't have un-saved changes when this is occuring, yet it is not reloading the files. It is somehow counting a file move, as "unsaved changes". This seems to be the crux of it.

For example, you can see nothing is unsaved, AFAIK this should be automatically re-loaded?

 

Is your test project using a lot of plugins? To reproduce what devs are seeing, I would buy 30 plugins or so, and put them in /plugins.

A good test case, simulating a real game, would have a solid 2000 class files in /Plugins, and at least 10-20 asmdef. Then you'd have a /script folder with a solid 100-200 classes.

This will also help you understand our load time pains, as VS can take a very long time to start the language server when there are so many deps and in general is just very slow to start and re-fresh (which would be totally fine, if it was a "once a day" thing and not "once every 10 minutes")

 

At this point I'm rolling back to 2017 because I actually can't work with the namespace imports constantly breaking. Fingers crossed.

fwiw, I can reliably get the namespaces to start working again by adding or removing a .cs file and letting VS reload assemblies. But it's a big PITA.

 

Rolling back to 2017 seems to have worked. I can now add/remove/move/rename files, the dialog never opens, and VS is never blocked. LETS GO!

Creating/removing asmdefs still triggers a modal, but I can live with that

One thing I noticed when installing 2017, is a firewall request that I approved. I wonder if this is somehow coming back to windows firewall, messing with the communication from VS to Unity somehow.

People seeing issues, maybe try turning off Windows Firewall temporarily?

 

I still have this problem where:
- You click a message on Unity Console to go there in VS
- It won't go to the line in VS
- The play button (Debug Button) turns in to a hammer. Cannot debug anymore.

Work around:
- Create a new script in Unity
- Go to VS
- It will reload the solution and will continue working.

Unity 2020.3.13f1
VS for Mac 8.10.7 (build 17)

 

@savantedroid

Can you check that you have the latest version of the Visual Studio Editor Package you have installed using Unity > Windows > Package Manager?

If that is up-to-date, we may have a bug we need to fix or need more info to help troubleshoot. Would you mind then filing an issue using the Help > Report a Problem menu in VS for Mac? Thank you!

 

I have exactly that!

 

@John_MSFT

Is it necessary for the shipped package to include a dependency on the Unity Test Framework? This in turn requires a dependency on NUnit. Removing these two dependences would speed up app domain reloads which is an issue many of us are suffering with in Unity 2020.x and 2021.x.

 

Does anyone get this dialog when clicking Attach to Unity? Know of any solutions or work-arounds?



* update. The error is resolved but I'm not 100% certain why. I cleared the MEF cache as suggested, and although I am fairly certain I retested after restarts of Unity and VS, I can confirm it is working now.

 

@stonstad I'm very stuck on this error (I posted in this thread about it) and getting desperate for new ideas to try. Can you tell me more about clearing the MEF cache?

 

I'm sorry, I don't have a solution to this behavior. I can confirm some of the behavior that I see 1) it is random, 2) system restarts sometimes help for a while. 3) it may be related to VS/Unity VS code not releasing a port, and the port is then in-use on subsequent connection ttempts.

I engaged the VS team, including @John_MSFT. They were unable to identify a cause or offer a fix. I gave up and switched to a more stable IDE.