It would be useful for some mock file generation to provide a request body, either as a string or a file or some other form, that the mock generator could use in its request. Some responses can only be generated this way.

See https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/a47b23e3ec200c9c05175d1d1b65388840d77920/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.Shared/Core/Networking.cs#L150

Docs on how to get the project up and running, details on picking a test app to work with, and how to add command line args to make it easy to debug.

See
https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/80764d1dc0db18d338f1e4e3d788811354cca079/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper/CertificateHandling.cs#L97
and
https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/58b60bb8819ef9ec35386d68a43c705d7ea4fd12/WindowsDevicePortalWrapper/UnitTestProject/WDPMockImplementations/CertificateHandling.cs#L97

If after investigation there's no good fix, please close as by design and remove the TODOs from the codebase.

Collecting dumps, both processes and crash dumps, is unimplemented.
This can be found in Shared/Core/DumpCollection.cs.

Documentation on the DumpCollection API can be found on MSDN

Since merging #72 all http requests (and thus tests) fail with the exception: {"The format of value 'WindowsDevicePortalWrapper/v0.9.0.0/dotnet' is invalid."}. I have traced this to ApplyUserAgentHeader which can be fixed by replacing the "/" characters with "-" characters.

Sending a HTTP request to "api/resourcemanager/systemperf", not via websocket, results in an exception due to the result being in the format of "{"Reason" : ""}" with the having been stringified twice. We need a workaround for this scenario so that this JSON message can be correctly parsed.

There is a GET and a PUT for these APIs. See https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/wdp-xboxsettings-api

This would be another good one to get in soon.

See: https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/a47b23e3ec200c9c05175d1d1b65388840d77920/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.Shared/HoloLens/MixedRealityCapture.cs#L319

Shared project\HoloLens\MixedRealityCapture.cs

Specifically the live streaming methods.

Device Portal advertises over DNS-SD so that other clients can find it. The Wrapper project should have a generic way of detecting and connecting to the service, regardless of what DeviceFamily it belongs to.

Docs for the DNS-SD broadcast are on MSDN

The ETW collection APIs for Core are unimplemented.
The stub file is in Shared/Core/Etw.cs
Docs for the ETW collection APIs can be found on MSDN

The WPR wrapper in Core is unimplemented.
It can be found in Shared/Core/WindowsPerformanceRecorder.cs
Docs for the WPR APIs can be found on MSDN

@MattHyman volunteered to take this one :)

Shared project\HoloLens\HolographicPerception.cs

ex: SetIpd on HoloLens

Note: this is for just the /api/dns-sd/tag[s] APIs, not the DNS-SD advertisement that Device Portal performs.

[From TODO]
See: https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/80764d1dc0db18d338f1e4e3d788811354cca079/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.Shared/DevicePortal.cs#L203

Off of the Contributing.md doc should be a Testing.md doc with information on writing tests and collecting mock data for them.

I'm trying to track down the best way to do this. Our Readme.md is already really stale and we need an automated process for it.

Linked to from Contributing.md should be a Testing.md doc that also explains how to run the tests. See @MattHyman 's issue #92 for the other sections.

The WER APIs in Core are unimplemented.
They can be found in Shared/Core/WindowsErrorReporting.cs
Docs for the WER API can be found on MSDN

Shared project\HoloLend\PerceptionSimulationPlayback.cs

There are only four remaining Xbox specific APIs (some of these will move to CORE in the future but they are Xbox only right now).

/api/app/packagemanager/upload
/ext/screenshot
/ext/xboxlive/sandbox
/ext/fiddler

for:

• Dragonboard 410c
• Minnowboard Max
• Raspberry Pi 2
• Raspberry Pi 3

Right now we can't determine anything about the version of WDPW which is calling WDP from the User-Agent header. We should get information added which will help out here.

One thing to keep in mind is that people forking the project, etc can complicate this beyond 'official released versions'.

Shared project\HoloLend\PerceptionSimulationRecording.cs

Right now we just check the response for these APIs. Occasionally the return interesting bodies--most notably in error situations many of the REST APIs will return JSON with the error code and sometimes a message. It would be great to propagate this up to callers so they can act on it.

Provide a basic implementation that can be used for applications across devices.

This would be useful functionality that we should investigate.

We might be able to use Credential storing built into Windows to store a username and password for a given IP. Storing a default IP could be done in a registry setting on a per-test app basis or via some other method (xbox already uses a reg setting for our other tools which is why I mention that).

See https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/b1d7e7f45b3ff330fc4c19538b2caf9365347457/WindowsDevicePortalWrapper/TestAppHL.UniversalWindows/App.xaml.cs#L61
and
https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/b1d7e7f45b3ff330fc4c19538b2caf9365347457/WindowsDevicePortalWrapper/TestAppHL.UniversalWindows/App.xaml.cs#L102

Can be closed as by design and remove TODO if there's no intention to support this resume/suspend behavior

when we issue the fetch for the CSRF token (set the token value to Fetch in Get requests), we do not appear to be getting the value back in the response. current assumption is that the header is not actually getting added to the Get request successfully

See:
https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/3e783f6ab4f9fda8b95ff01863764e5b4fff2514/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.Shared/Exceptions/DevicePortalException.cs#L148

[ @davidkline-ms - not sure what this TODO meant]

This should have 'first steps' for using the library along with device specific steps for each device type.

We should link to it in the Contributing.md.

[From TODO]
See https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/80764d1dc0db18d338f1e4e3d788811354cca079/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.Shared/DevicePortal.cs#L200

Suggested behavior: N/A - suggestions welcome

See https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/80764d1dc0db18d338f1e4e3d788811354cca079/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.Shared/DevicePortal.cs#L140

See: https://github.com/Microsoft/WindowsDevicePortalWrapper/blob/58b60bb8819ef9ec35386d68a43c705d7ea4fd12/WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.Shared/Core/OsInformation.cs#L135
This might be tying the implementation of the API wrapper too much to the calling code (e.g. if it's single shot, perhaps there shouldn't be a reconnect?)