search

dotnet / project-system

The .NET Project System for Visual Studio
MIT License
969 stars 387 forks source link

Intellisense issue with referenced assembly #5239

Closed vsfeedback closed 5 years ago

vsfeedback commented 5 years ago

This issue has a corresponding ticket on Developer Community. Please vote and comment there to make sure your voice is heard.

Hi,

It seems that there are issues with Intellisense when referencing a class library in a nanoFramework application. The build goes fine without any errors or warnings, but the colouring of the objects does not work as it doesn't the navigation using F12.

All this works fine in VS2017 using the same projects/solutions.

As a side comment, if the class library project is in the same solution as the other project and the project is referend (instead of directly referencing the DLL file) the result is the same.

Original Comments

José Simões on 5/6/2019, 05:14 AM

Forgot to mention that you'll need nanoFramework extension installed for these project system to work.

https://marketplace.visualstudio.com/items?itemName=nanoframework.nanoFramework-VS2019-Extension

Visual Studio Feedback System on 5/6/2019, 07:38 PM

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

José Simões on 5/23/2019, 05:40 PM

Could this be related:

https://developercommunity.visualstudio.com/content/problem/528953/intellisense-references-not-working.html

Visual Studio Feedback System on 7/22/2019, 01:55 PM

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

José Simões on 7/25/2019, 08:04 AM

Still not working after updating to 16.2...

David Weaver on 7/25/2019, 08:50 AM

I can confirm just tried it and it doesn't work after update.

Visual Studio Feedback System on 7/25/2019, 03:14 PM

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Visual Studio Feedback System on 7/29/2019, 04:45 PM

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

valoni commented 5 years ago

still no update about this fix

hoped this will be fixed on 16.3 release??

jjmew commented 5 years ago

@swesonga is currently investigating it

still no update about this fix

hoped this will be fixed on 16.3 release??

drewnoakes commented 5 years ago

@valoni are you also using nanoFramework?

valoni commented 5 years ago

@drewnoakes - YES

drewnoakes commented 5 years ago

Thank you for confirming. @swesonga will investigate further. It seems likely that nanoFramework is doing something in its targets that is causing the design-time build to break.

josesimoes commented 5 years ago

It could be... The targets was adapted, along with the rest of the project system, from the oficial C# one. The reason for it was that creating a sub-project for an exisiting language is still very opaque and obscure with the "new" VS extensibility API. So we had to adapt. 😉

networkfusion commented 5 years ago

For reference, this is the link to the targets files: https://github.com/nanoframework/nf-Visual-Studio-extension/tree/develop/source/VisualStudio.Extension-2019/Targets

drewnoakes commented 5 years ago

The targets provided by Visual Studio necessarily must change between versions. We aim to keep these changes small and only make them when necessary. However any time an extension replaces a target that's bundled with VS, that extension must be tested again with each version of VS.

The Project System Tools are an invaluable utility for debugging issues with design time builds.

https://github.com/dotnet/project-system-tools https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.ProjectSystemTools

josesimoes commented 5 years ago

@drewnoakes wasn't aware of these tools. I'm installing these right away!

networkfusion commented 5 years ago

@drewnoakes We have used the Project System Tools to take logs from both VS2017 and VS2019 and I have been through them with a fine tooth comb... Although there are some differences, we cannot find anything suspect that would cause the issues we are seeing.

Is there anywhere with an extensive changelog that we can use. Also I can send the logs we have generated if helpful.

Finally, after spending more time with the issue, the main symptom of it seems to be that VS2019 intellisense is not using the nanoFramework specific mscorlib (nostdlib is set), but another one (possibly .net4.x) as it will quite happily help you to write System.Web.AspNetHostingPermission.RevertAll; and give no warnings or errors until a manual build is attempted. As well as intellisense not seeing other project / nuget class libraries, and the object browser not working.

FYI, the builds are generating IL code in winPE format with an extra step where the metadata processor gives it an extra pass to distyle the PE to nF format..

networkfusion commented 5 years ago

image

swesonga commented 5 years ago

@networkfusion I had also compared the project system logs from VS2017 and VS2019 and didn't see anything that stood out as unusual. I can successfully reproduce the behavior you have described, so there's no need to share log files at this time. As for changelogs, note that VS2017 used the LanguageServiceHost which was removed in https://github.com/dotnet/project-system/commit/b102468acb45da4360fb65e788c05e83b487d68e. I'm still investigating the different behavior in the refactored code in VS2019 to determine exactly what needs to change.

swesonga commented 5 years ago

@networkfusion Could you check whether the intellisense issue is resolved by including the LanguageService project capability and the language service properties listed in the commit at https://github.com/swesonga/nf-Visual-Studio-extension/commit/b53d5b22d71af43bb20622395e93dd3986eb21cf

networkfusion commented 5 years ago

@swesonga YOU ARE THE MAN! I have tested your changes and it does indeed fix all of the issues we have been experiencing. Would you like to raise a PR? If not, I will...

swesonga commented 5 years ago

@networkfusion Glad to hear that commit resolves the issues you ran into. I'm investigating other issues as well so I'll close this issue and let you handle the PR on the nanoFramework side.

networkfusion commented 5 years ago

@swesonga Okay... PR raised. Thanks again!

swesonga commented 5 years ago

@davkean Could you please take a look at the fix I suggested for this issue and see whether the project system should use IUnconfiguredProjectCommonServices or some other mechanism to work around a case where important properties are missing. Or whether this is something that the project system diagnostic tools should be looking for.

davkean commented 5 years ago

We warn in other situations when missing properties are missing, we should the same here. Building on top of our project system is not a supported scenario at the moment and this will be a constant moving target until https://github.com/dotnet/project-system/issues/4104 is fixed.

networkfusion commented 4 years ago

@swesonga another issue has cropped up when we are trying to open embedded resource files where VS2019 tries to open the file forever... Is there any suggestions that you can give of commits/changes that are related to this since this issue was closed? Many Thanks...

drewnoakes commented 4 years ago

@networkfusion please open a new issue, ideally within VS itself so we can gather data about what's happening while VS is stuck.

See this doc for details of how to record a repro:

https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019