Unity 2017 LTS not recognizing VS2019

Hi,
Has anyone had this problem? I had a 2017.4.18f (now also currently updated to last 2017.4.20f2) that isn't able to build the HoloLens UWP project even though I've set the path to the Visual Studio's devenv.exe in the Edit>Prefrerences>External Tools manually and in the drop-down now says VS2019 experimental...I realize it's an old LTS version of Unity and that VS2019 comes with Unity 2018, but LTS is the recommended version of Unity for HoloLens UWP so shouldn't the two be working nicely, instead of Build giving me "Could not find any supported Visual Studio installations" (or did I miss to install something with my VS2019 Preview 2.0 which had Unity 2018 selected to be installed but got uninstalled after but I skipped the C++ Game and Desktop development bundles as those weren't needed ever before).

 

Hey. April 11th 2019, VS2019 is already released, and this problem is still present with the version of Unity 2017.4.25f1. Unfortunately, the poor quality of products and support is normal for Unity. Good luck!

 

- The VS extension for Unity is maintained by Microsoft.
- The LTS version means NO NEW FEATURE, only BUG FIX.

So no and no, 2017 should not get a new feature.

But don't mind me, please, go ahead and continue to bash blindly in the void about software quality without a clue what you're talking about.

 

This. If you're already holding back on releases of Unity it's a safe bet you should be doing the same for Visual Studio. It's not like you gain any advantages to getting newer releases of Visual Studio. Unity only uses it as an IDE.

With the only exception to date being 64-bit support for Android which will soon be a showstopper.

https://blogs.unity3d.com/2019/03/0...bit-and-app-bundles-backported-to-2017-4-lts/

 

I consider that as a bug fix, but obviously, maintenance is never black and white.

 

And according to what logic do you attribute something to the bug fixes or to the new functionality, if it is not black and white? Sounds like a universal excuse for all occasions.

 

Personally I test against some questions:

Did Android support exist beforehand?
- Yes
Did it break?
- Yes
Bugfix.

Did Android support exist beforehand?
- No
New feature.


But you can ask the question on other ways:
Does the 64bit Android support exists?
- No
New feature.

But also, you can argue that it's an externally forced change in a working system, so it has to be a bug fix.

---
So why? And what 'excuse'?

 

VS 2019 mostly works with 2017 LTS now but the unity explorer window and debugging do not seem right in VS 2019. Anyone got it working as well as VS 2017?

 

The fault seems to be in the Assembly-CSharp.csproj not including the new syntax like below, is it Unity or MS's fault?

Code (CSharp):

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

MS have recognised it as a Unity bug, please fix @Unity:
https://developercommunity.visualst...dio-2019-tools-for-unity-4005-not-workin.html

 

After spending a couple minutes searching the Issue Tracker I'm not convinced anyone reported it yet. By the way @Unity is not an actual Unity employee. It's just a random account someone made and they haven't logged on in three years.

 

I have now reported it (@Unity should trigger a red light in the support room! But yep - useless)