Add implementation for NativeSetDeviceName

[zandiarash]

Description

• Add implementation for NativeSetDeviceName().
• Update declaration of System.Device.Wifi library.

Motivation and Context

• Following nanoframework/System.Device.Wifi#322

I should mention that I am not familiar with C++ and after I changed nf-interpreter project I flashed my chip like this

nanoff --platform esp32 --target ESP32_REV3 --serialport COM6 --update  --clrfile "D:\Sources Electronic\Nanoframework - Copy\nf-interpreter\build\nanoCLR.bin"

How Has This Been Tested?

Screenshots

Before : After :

Types of changes

• [x] Improvement (non-breaking change that improves a sample)
• [ ] Bug fix (fixes an issue with a current sample)
• [ ] New Sample (adds a new sample)
• [x] Dependencies/declarations (update dependencies or assembly declarations and changes associated, has no impact on code or features)
• [ ] Config and build (change in the configuration and build system, has no impact on code or features)
• [ ] Documentation/comment (fixes and improvements documentation related)

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.

Summary by CodeRabbit

• New Features

  • Added ability to set the device hostname via the WifiAdapter API for easier identification on Wi‑Fi networks.

• Platform Notes

  • Implemented on ESP32 targets (hostname applied to the network interface).
  • On some RTOS targets this API is a stub/not implemented or a no-op; behavior may vary by platform.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai[bot]]

Walkthrough

Adds a native WifiAdapter method to set the device hostname: header declaration, registration in the platform‑neutral native method table (an extra NULL slot and updated assembly CRC), an ESP32 implementation that sets the STA netif hostname, and AzureRTOS stubs (NOTIMPL/no‑op).

Changes

Cohort / File(s)	Summary
Native interface declaration src/System.Device.Wifi/sys_dev_wifi_native.h	Added NativeSetDeviceName___VOID__STRING declaration to Library_sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.
Method registration & assembly identity src/System.Device.Wifi/sys_dev_wifi_native.cpp	Inserted NativeSetDeviceName___VOID__STRING into the public/native method table (placed before NativeFindWirelessAdapters___STATIC__SZARRAY_U1), added an extra NULL slot earlier in the table (shifting subsequent entries), and updated g_CLR_AssemblyNative_System_Device_Wifi CRC from 0x00A058C6 to 0x030E2768; adjusted public data initializer count.
ESP32 platform implementation targets/ESP32/_nanoCLR/.../sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp	Added #include <esp_netif.h> and implemented NativeSetDeviceName___VOID__STRING(CLR_RT_StackFrame&): read/validate hostname, resolve STA netif via esp_netif_get_handle_from_ifkey("WIFI_STA_DEF"), call esp_netif_set_hostname, map non-ESP_OK results to CLR errors; guarded by SOC/WIRELESS config macros.
AzureRTOS/ST platform implementation targets/AzureRTOS/ST/_nanoCLR/.../sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp	Added NativeSetDeviceName___VOID__STRING(CLR_RT_StackFrame&) returning CLR_E_NOTIMPL; removed esp_wifi_types.h include; added no-op NativeInit___VOID; minor whitespace/formatting edits.

Sequence Diagram(s)

sequenceDiagram
    participant Managed as Managed (C#)
    participant CLR as nanoCLR native entry
    participant ESP as esp_netif / ESP-IDF

    Managed->>CLR: Invoke NativeSetDeviceName(string hostname)
    CLR->>CLR: Read & validate hostname argument
    CLR->>CLR: (optional) validate network interface index
    CLR->>ESP: esp_netif_get_handle_from_ifkey("WIFI_STA_DEF")
    ESP-->>CLR: netif handle or NULL
    alt netif found
        CLR->>ESP: esp_netif_set_hostname(netif, hostname)
        ESP-->>CLR: esp_err_t (ESP_OK / error)
        CLR-->>Managed: return success or mapped CLR error
    else netif not found
        CLR-->>Managed: return CLR_E_INVALID_OPERATION (or mapped error)
    end

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify ESP32 hostname handling: length, allowed characters, and error-to-CLR mappings.
• Confirm config-guard macros (CONFIG_SOC_WIFI_SUPPORTED / CONFIG_SOC_WIRELESS_HOST_SUPPORTED) and build conditional paths.
• Check consistency of the extra NULL slot and method table ordering across native tables and the updated assembly CRC/public data initializer.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly describes the main change: implementation of a new NativeSetDeviceName method across multiple files (native declarations and platform-specific implementations).

✨ Finishing touches

• [ ] 📝 Generate docstrings

🧪 Generate unit tests (beta)

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7b1720d236f8a3aa0c4896f7561d62c181f17fb8 and 0deede79025650ee0806a2d3260accabe81853ce.

📒 Files selected for processing (1)

• src/System.Device.Wifi/sys_dev_wifi_native.cpp (2 hunks)

🧰 Additional context used

🧠 Learnings (3)

📓 Common learnings

Learnt from: josesimoes
Repo: nanoframework/nf-interpreter PR: 3243
File: targets/ESP32/_nanoCLR/System.Device.Wifi/sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp:31-50
Timestamp: 2025-12-02T09:32:22.318Z
Learning: In the nanoFramework WiFi implementation, hostname length validation for NativeSetDeviceName___VOID__STRING in targets/ESP32/_nanoCLR/System.Device.Wifi/sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp is performed at the caller level (managed code), not in the native implementation.

📚 Learning: 2025-12-02T09:32:22.318Z

Learnt from: josesimoes
Repo: nanoframework/nf-interpreter PR: 3243
File: targets/ESP32/_nanoCLR/System.Device.Wifi/sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp:31-50
Timestamp: 2025-12-02T09:32:22.318Z
Learning: In the nanoFramework WiFi implementation, hostname length validation for NativeSetDeviceName___VOID__STRING in targets/ESP32/_nanoCLR/System.Device.Wifi/sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp is performed at the caller level (managed code), not in the native implementation.

Applied to files:

• src/System.Device.Wifi/sys_dev_wifi_native.cpp

📚 Learning: 2024-10-12T19:00:39.000Z

Learnt from: josesimoes
Repo: nanoframework/nf-interpreter PR: 3023
File: targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp:191-225
Timestamp: 2024-10-12T19:00:39.000Z
Learning: When working with `nanoCLR_GetNativeAssemblyInformation`, fixed-size assembly names are required, so code that deals with variable-length names cannot be used.

Applied to files:

• src/System.Device.Wifi/sys_dev_wifi_native.cpp

🧬 Code graph analysis (1)

src/System.Device.Wifi/sys_dev_wifi_native.cpp (2)

targets/AzureRTOS/ST/_nanoCLR/System.Device.Wifi/sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp (2)

• NativeSetDeviceName___VOID__STRING (60-68)
• NativeSetDeviceName___VOID__STRING (60-61)

targets/ESP32/_nanoCLR/System.Device.Wifi/sys_dev_wifi_native_System_Device_Wifi_WifiAdapter.cpp (2)

• NativeSetDeviceName___VOID__STRING (25-61)
• NativeSetDeviceName___VOID__STRING (25-26)

🔇 Additional comments (3)

src/System.Device.Wifi/sys_dev_wifi_native.cpp (3)

88-88: Metadata count increment is consistent with adding a new method.

The change from { 100, 0, 6, 4 } to { 100, 0, 6, 5 } reflects the addition of one new method to the assembly. This mechanical update should be automatically generated by the build tooling.

---

86-86: Assembly CRC update is correct.

The CRC change from 0x00A058C6 to 0x030E2768 correctly reflects the assembly structure modification in this version bump, along with the updated version tuple { 100, 0, 6, 5 }. The runtime uses this value to verify native/managed assembly compatibility.

---

36-43: Method table updates are correct and consistent with adding NativeSetDeviceName.

The method_lookup table properly adds the NativeSetDeviceName___VOID__STRING entry at line 43 with a corresponding NULL placeholder at line 44 (managed method slot without native implementation). The CRC and metadata count changes reflect this addition correctly.

The implementation is present in both ESP32 (full implementation) and AzureRTOS (stub). The method table ordering aligns with the implementation files.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Ellerbach]

@zandiarash please also use the proper PR template.

[Ellerbach]

Also, please adjust all the native devices. It's find to throw an exception but the build of other devices than ESP32 will break.

[Ellerbach]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[zandiarash]

@zandiarash please also use the proper PR template.

Thank you for the guidance. I’ve updated the pull request to use the proper template.

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[zandiarash]

\azp run To maintain a clean and linear commit history, should I make all commits as a single commit ?

[josesimoes]

\azp run To maintain a clean and linear commit history, should I make all commits as a single commit ?

If you can do it, that's preferable.

[zandiarash]

\azp run To maintain a clean and linear commit history, should I make all commits as a single commit ?

If you can do it, that's preferable.

@josesimoes I’ve already made everything into a single commit (your review messages and bot suggestions).👍

[josesimoes]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[josesimoes]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[zandiarash]

@josesimoes @Ellerbach May I kindly ask if there is anything pending on my side, or if there is any update regarding the merge process? If there is anything further needed, I would be happy to do.

[josesimoes]

@zandiarash no further changes required. Waiting to complete other tasks and get to this one. Please hold.

[josesimoes]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[josesimoes]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[nfbot]

@zandiarash thank you again for your contribution! :pray::smile:

.NET nanoFramework is all about community involvement, and no contribution is too small. We would like to invite you to join the project's Contributors list.

Please edit it and add an entry with your GitHub username in the appropriate location (names are sorted alphabetically):

  <tr>
    <td><img src="https://github.com/zandiarash.png?size=50" height="50" width="50" ></td>
    <td><a href="https://github.com/zandiarash">Arash Zandi</a></td>
  </tr>

(Feel free to adjust your name if it's not correct)