Project-system: Support remote debugging project properties and expose in app designer

[rainersigwald]

_From @TFTomSun on July 18, 2018 11:10_

Using the old MSBuild Format it was possible to specify remote debugging settings like this:

  <PropertyGroup>
    <StartAction>Program</StartAction>
    <StartProgram>C:\MyRemote\Executable.exe</StartProgram>
    <RemoteDebugEnabled>true</RemoteDebugEnabled>
    <RemoteDebugMachine>MyRemoteMachine</RemoteDebugMachine>
  </PropertyGroup>

These properties seem to be not be evaluated by the new MSBuild Format, even if the Project is marked as a Net4.6.1 project.

Is that a bug or does the new MSBuild Format don't support remote debugging by simply starting debugging anymore?

_Copied from original issue: Microsoft/msbuild#3524_

[rainersigwald]

That should continue to work from the MSBuild perspective. What errors are you seeing? How do you know it's not working? I've never used remote debugging, so I don't know how to investigate.

[rainersigwald]

_From @TFTomSun on July 18, 2018 19:39_

First off all, when the new sdk based MSBuild Format is used, the remote debugger settings in the project properties are not available anymore. When I manually set the remote debugger settings in the csproj file, it still does start a local debugging… It seems like the MSBuild properties are ignored. When the project is created using the old MSBuild Format, remote debugging works fine even with the latest VS 2017 Version.

[rainersigwald]

_From @jp2masa on July 19, 2018 18:23_

The problem is probably that the feature hasn't been implemented in the .NET SDK: https://github.com/dotnet/sdk.

[rainersigwald]

Based on the description, I think it might be that it's not implemented yet in the new project system. I'll move this over there; if I'm wrong and it's actually the SDK we can move it there instead.

[Pilchie]

@BillHiebert is this something that can be specified in the launch profile now?

[BillHiebert]

@Pilchie - If I understand the scenario correctly, then no, as there are no provisions in launch settings to pass the remote information to the debugger.

[MagicAndre1981]

any status update? When can we get the remote debug option back?

[TFTomSun]

I would be interested in an update, too.

@pilchie why is it not marked as bug? At least for .net framework projects i would expect backward compatibility

[drewnoakes]

From a brief look it seems we need to set IDebugLaunchSettings.RemoteMachine.

[rcurtis]

Has there been any update on this? This is a major blocker for migrating to the new csproj format and dotnet core.

[davkean]

@rcurtis We will be adding remote debugging support in .NET 5 timeframe, which does not yet have a date.

[MagicAndre1981]

way to long. So we need to wait 1 more year for a basic feature 🤦‍♂️

[TFTomSun]

For all who are interested in a workaround: I've created a sdk package (RemoteDebugging.Sdk) that is recognized as a old format project. I add a project with this sdk always then when I need remote debugging support. It doesn't contain any sources, it just contains the remote debugging settings for a real SDK style project next to it. The remote debugging project references the SDK style project via Project Reference, so that the actual Project to debug is always built, wenn I start the remote debugging operation.

[MagicAndre1981]

Can you post a demo which shows your SDK? @TFTomSun

[MagicAndre1981]

@TFTomSun any update? Can you share the SDK? Or is this not allowed?

[TFTomSun]

@MagicAndre1981 I've published the package: RemoteDebugging.Sdk

Use it in the following way.
example you want to remote debug the project: MyTool
create another project "MyTool.RemoteDebug"
with the following content:

<Project  ToolsVersion="Current">
  <Sdk Name="RemoteDebugging.Sdk" Version="1.0.0" />
</Project>

The sdk supports remote debugging of Nunit test libraries and Applications and presets the remote debugging settings for a click once remote debugging experience.
It expects your local repository to be network shared to the remote machine

[rcurtis]

@TFTomSun Where is this package? Can you provide a demo repo?

[TFTomSun]

@rcurtis here: https://www.nuget.org/packages/RemoteDebugging.Sdk/

as mentioned, just create a project with the package as a sdk dependency. Did you try that already? Which part is unclear?

[rcurtis]

@TFTomSun Ok, so I added your package with Nuget. What now? The Debug menu is still lacking the 'Use Remote Machine' option. I'm not sure where I would add the included xml you linked:

<Project ToolsVersion="Current"> <Sdk Name="RemoteDebugging.Sdk" Version="1.0.0" /> </Project>

A demo repo or a working example would really answer a lot of questions.

[TFTomSun]

@rcurtis the xml is the content of the remote debugging project file (csproj). don't add the package via nuget cli or package manager. they don't add sdk packages properly.
I'll create a repo if i find the time. but since you need to apply it on your project i don't see how a repo would help

[MagicAndre1981]

example you want to remote debug the project: MyTool
create another project "MyTool.RemoteDebug"
with the following content:

<Project  ToolsVersion="Current">
  <Sdk Name="RemoteDebugging.Sdk" Version="1.0.0" />
</Project>

ok, this works, I see the remote debugging options again in this extra project. But it has the drawback that I can't add nuget packages to it to do the robocopy task to copy folder to remote device in that project.

It also skips my modifications Directory.Build.props/Target in root directory where I did solution wide modifications (obj/bin locations). I'll play with it a bit more.

[TFTomSun]

@MagicAndre1981 my approach is not to copy anything and use network sharing instead to start the application directly from the binary output of the dev machine. In general i am not a fan of duplication. if you want to add copy build steps you can do that by overriding the build target. you could use the dotnet cli to install a package and call a target from there. If you rely on the old build system (to resolve packages) the remote debugging project would break the build in a .net core only environment (e. g. linux docker image), which i had first, but wasn't an acceptable tradeoff.

Another option would be to add ur robocopy packages to the actual project that contains the code.

The project does not produce any output on its own that's why i didn't add the ability to apply directory.build.props or targets hooks. there might also be some unwanted side effects of those hooks, because the sdk behaves different than the standard Microsoft sdk...anyway that feature could be added easily.

[MagicAndre1981]

When I set the option to "use remote machine", entered the name:Port I see in remote debugger but application runs on local device.

please provide an demo repo here on github with an application and the remote debug project which explains how to use it. As you can see me and @rcurtis are not able to understand your idea.

You could also write a blog post or codeproject article about it and how to use it.

[TFTomSun]

@MagicAndre1981 can you make a screenshot of the debug settings in the RemoteDebug project? Maybe there's a case that i didn't cover. Did you set the remotedebug project as startup project?

[MagicAndre1981]

I can't set it as startup, here I get an error message:

sln.metaproj : error MSB4057: The target "foo" does not exist in the project.

Please provide a working demo.

[TFTomSun]

Is "foo" a target that is defined in your build environment? Seems like your build is customized in a not standard way.

[MagicAndre1981]

no, I replaced my app name with foo. I selected the 2 nd option and specified the exe and when I set the Foo.remotedebug as startup I get this error during compile/start

[MagicAndre1981]

@TFTomSun

ok, I used VS2017 and now I tried it in VS2019 and here it works.

[davkean]

We're adding basic remote debugging support in https://github.com/dotnet/project-system/pull/5784, we'll follow that up with the full support that UWP projects have as we bring up WinUI support for .NET 5 this year.

[MagicAndre1981]

@davkean when will this be part of VS2019? 16.5? What do you mean with full support like UWP? Automatic copy to remote target? That will be huge, it was always a pain to do this in PostBuild Event

[davkean]

Yes in 16.5. A machine selection UI, being able to select authentication and possible deployment.

[drewnoakes]

To be clear, 16.5 will have basic support (specifying a host name) as implemented in #5784.

Some later release, as yet unspecified, will have the richer UWP-style remote debugging support.

[MagicAndre1981]

yes, I understood it already this way. Thanks for clarification @drewnoakes