search

dotnet / maui

.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://dot.net/maui
MIT License
21.98k stars 1.72k forks source link

Enable VS 2022 "External Sources", Source Link, and/or Source Server #4299

Open IndianaGary opened 2 years ago

IndianaGary commented 2 years ago

Description

In August 2021, the Microsoft Visual Studio team announced the addition of the "External Sources" node that appears in Solution Explorer when in a debugging session. The blog post announcing this feature can be found here: https://devblogs.microsoft.com/visualstudio/debugging-external-sources-with-visual-studio.

I've attempted to use this tool with Maui without success as apparently neither a Source Server nor Source Link is enabled. Detailed debug symbols are downloaded but an attempt to access source code fails. I have a number of applications I am porting from Xamarin Forms that use low-level features, such as Effects and Renderers, and source-level debugging deep into Maui is the only way to figure out what is wrong with the code. Unfortunately, many developers like myself, do not have the resources (neither time nor hardware to dedicate) to build Maui locally.

On GitHub, each time a Preview or RC is released, the Maui repo is branched so that the source code for that release is frozen. My request is that when the code is branched, that either a Source Server be established or updated as part of the CI stream or that the source code be indexed and available via Source Link. There are a number of potential benefits from implementing this feature:

  1. Lower maintenance cost to Microsoft by reducing the number of support calls, especially some of the more complex issues.
  2. Increased community engagement and participation in the further development of Maui.
  3. Further indication of Microsoft's commitment to the developer community.

I respectfully request that this feature request be considered and implemented as soon as possible.

Public API Changes

None

Intended Use-Case

I have an example: I am porting a set of controls that use SkiaSharp on Maui. There is an Effect implemented that I am presently trying to debug. Unfortunately, registration of an effect goes through several internal layers of Maui code that are opaque without the ability to use source code debugging into Maui code. I am currently stymied and unable to continue troubleshooting without the assistance of a Maui developer. These developers have been great and very helpful, but their time is a limited resource that should be dedicated to less time-consuming side-issues and more productive endeavors. Making it possible for the developer community to do deep troubleshooting would go a long way to making Maui the success it deserves to be.

nextfool commented 2 years ago

It would be great to have this!

thoys commented 1 year ago

Was looking for just right now, bump! Would be great to have this and it would definitely would get better contributions to the project since people can debug problems directly with the source.

linkaiyu commented 1 year ago

Please make this work as it would save everybody a lot of time when debugging at low level

Redth commented 1 year ago

https://github.com/dotnet/maui/pull/11206 should eventually help with this too since the pdb's will be in the nuget packages. The change is a little ways away from being usable, but wanted to link this issue with the PR.

PureWeen commented 1 year ago

Related https://github.com/dotnet/maui/issues/10654

homeyf commented 9 months ago

Reference Related #10654.

tomwimmenhove commented 7 months ago

Is there a way you could have it not show results when searching in the Solution Explorer. I keep accidentally clicking on source files that I have locally, only to realize it was under the "External sources" node instead of on my hard drive.

johnmschneider commented 5 months ago

Is there a way you could have it not show results when searching in the Solution Explorer. I keep accidentally clicking on source files that I have locally, only to realize it was under the "External sources" node instead of on my hard drive.

I had a similar issue, and it appears this can be disabled by going to "Tools -> Options", search for "External sources", and then under "Debugging -> General", un-check "Enable the External Sources node in Solution Explorer".

TheXenocide commented 4 months ago

I am also trying to troubleshoot a migration where Source Link would be immensely helpful.

bytesandwich commented 2 weeks ago

Hello - I’m very excited to see this feature on the backlog and to eventually have debuggable Maui source. While this remains on the backlog, is there some workaround to debug Maui code, like for example to set a breakpoint in VisualElement.cs and step through it?

bytesandwich commented 1 week ago

My best advice to debug Maui

In lieu of the authors providing a workaround to debug Maui code, I will share the results of my own investigation.

It seems like the most reliable way to debug Maui apps and also see the full source is to use the developer sandbox app. For anyone trying to debug Maui apps and see the Maui code that's running, these are the steps I've found to do that:

Another possible route - linking to a downloaded copy of maui

I tried linking my existing project to the maui source, but the amount of references and links was more than I could figure out. If you want to pursue this, I'd recommend looking at the sandbox csproj and trying to copy it into your csproj - https://github.com/dotnet/maui/blob/main/src/Controls/samples/Controls.Sample.Sandbox/Maui.Controls.Sample.Sandbox.csproj

Another possible route - building maui locally and using the developer cake tools

I think it may also be possible to build and use Maui locally and link a new project to it, following the developer set up https://github.com/dotnet/maui/blob/main/docs/DevelopmentTips.md#advanced-scenarios

This seems to create a whole clone of dotnet, which I suspect is necessary because of the dotnet workload coupling? Anyway this seems very heavyweight (heavyweight because AFAICT you have to really build and mock out the whole universe of dotnet and many not-simple packages like https://github.com/dotnet/maui/blob/main/docs/design/NuGets.md but someone please correct me if I'm wrong!) to have to use a local build of maui and I wouldn't recommend it. If your company has a dedicated build engineer than creating your own Maui packages and workload packages, and putting them into your own nuget package repo is probably the way to go to provide a good developer experience here.