Metadata of native assemblies is now generated and exposed in virtual device #3023
Conversation
…s built. This is done by CMake that reads the data in the source files. The native_assemblies.csv file lists name, version and checksum for the included native assemblies. - Extra options --getnativeassemblies and --clrinstancepath added to nanoclr.exe (and corresponding code to the native CLR host). This produces a list of name, version and checksum for the native assemblies included in the runtime embedded in nanoclr.exe or external file. Can still be used with "old" runtimes. - .editorconfig added It would be great if the latest version of each firmware package on cloudsmith would be re-created (with the same version number) so that the `native_assemblies.csv` files are part of the packages. I have no idea how to make that happen. Signed-off-by: Frank Robijn <robijn@good-heavens.nl>
nfbot
changed the title
WalkthroughThe pull request introduces a new Changes
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
Outside diff range and nitpick comments (12)
targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsOptions.cs (1)
45-51: LGTM: New property for specifying local instance pathThe
LocalInstanceproperty has been correctly implemented as a string option. Its purpose aligns with the PR objectives of ensuring compatibility with older runtimes. TheOptionattribute is properly configured, and theHidden = trueparameter is appropriate for this advanced option.Consider slightly rewording the help text for clarity:
- HelpText = "Path to the directory where a local version of nanoFramework.nanoCLR.dll is located.")] + HelpText = "Path to the directory containing a local version of nanoFramework.nanoCLR.dll.")]targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.h (1)
71-71: New function declaration looks good, consider adding documentationThe
nanoCLR_GetNativeAssemblyCount()function declaration is well-formed and consistent with the existing code style. It's purpose is clear from the name, but consider adding a brief comment to describe its functionality and any potential limitations (e.g., maximum count).Consider adding a brief documentation comment:
/// @brief Get the count of native assemblies /// @return The number of native assemblies (max 65535) extern "C" NANOCLRNATIVE_API uint16_t nanoCLR_GetNativeAssemblyCount();targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs (1)
94-96: LGTM: New method for accessing native assembliesThe new
GetNativeAssemblies()method provides a clean way to access native assembly details, aligning with the PR objectives. The implementation is concise and uses modern C# syntax.Consider adding XML documentation for this new public method to improve API usability. For example:
/// <summary> /// Retrieves a list of native assembly details. /// </summary> /// <returns>A list of NativeAssemblyDetails objects.</returns> public List<NativeAssemblyDetails> GetNativeAssemblies() => NativeAssemblyDetails.Get();targets/netcore/nanoFramework.nanoCLR.Host/Interop/nanoCLR.cs (2)
96-97: LGTM: New method for retrieving native assembly information. Consider adding a comment about buffer size.The
nanoCLR_GetNativeAssemblyInformationmethod is well-defined and consistent with the existing code style. It aligns with the PR objectives to retrieve detailed native assembly information.Consider adding a comment to clarify the expected buffer size or any potential risks of buffer overflow. For example:
/// <summary> /// Retrieves information about native assemblies. /// </summary> /// <param name="buffer">Buffer to store the assembly information. Ensure it's large enough to hold all data.</param> /// <param name="size">Size of the provided buffer.</param> /// <remarks> /// Caller is responsible for providing a buffer large enough to hold all assembly information. /// Use nanoCLR_GetNativeAssemblyCount to determine the number of assemblies and allocate accordingly. /// </remarks>
93-97: Overall impact: Positive addition with minimal risk. Consider updating documentation.The new methods
nanoCLR_GetNativeAssemblyCountandnanoCLR_GetNativeAssemblyInformationare well-integrated into the existing codebase. They provide the functionality described in the PR objectives without modifying existing code, which minimizes the risk of unintended side effects.Consider the following suggestions:
- Update any relevant documentation or usage examples in the project to reflect these new capabilities.
- If not already planned, consider adding unit tests for the new functionality to ensure it behaves as expected.
- Verify that any code that will use these new methods handles potential exceptions (e.g., DllNotFoundException) appropriately.
targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs (1)
70-70: Ensure compatibility ofusing varsyntax with target frameworksThe use of
using varrequires C# 8.0 or later. Ensure that all target environments support this syntax. If not, consider using traditionalusingstatements for broader compatibility.targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.cs (3)
31-32: Provide informative error messages in exceptionsWhen throwing
CLIException, consider including an informative message to help users understand the issue. For instance, specify that--localinstanceand--updateclroptions cannot be combined.
38-38: Provide informative error messages when the local instance path is invalidWhen the specified local instance path does not exist, include a clear error message in the
CLIExceptionto inform the user that the directory was not found.
84-87: Inform the user when native assembly information is not availableIf
nativeAssembliesisnull, the message indicating that the CLR instance is too old is only displayed at verbosity levels above normal. Consider showing this message at normal verbosity to inform users why no native assembly information is displayed..editorconfig (2)
15-15: Consider using UTF-8 without BOM for character encodingSpecifying
charset = utf-8-bommay introduce issues with tools that do not expect a Byte Order Mark (BOM). It's generally recommended to useutf-8without BOM to improve compatibility across different environments.Apply this diff to adjust the encoding:
-charset = utf-8-bom +charset = utf-8
64-64: Clarify the comment to prevent confusionThe comment on line 64 may be misleading because the word "this" can be mistaken for the C#
thiskeyword. To enhance clarity, consider rephrasing the comment.Apply this diff to improve the comment:
-# avoid this. unless absolutely necessary +# Avoid using `this.` qualification unless absolutely necessaryCMake/Modules/FindNF_NativeAssemblies.cmake (1)
486-488: Ensure Proper Line Endings in Generated CSV FileThe
string(REPLACE ";" "\r\n" ...)command replaces semicolons with Windows-style line endings. If the build is performed on a Unix-based system, this could cause issues with tools expecting Unix-style line endings.Consider using
\ninstead of\r\nfor consistency across different environments, or configure the line endings based on the operating system.Apply this diff to adjust the line endings:
-string(REPLACE ";" "\r\n" NF_NativeAssemblies_CSV "${NF_NativeAssemblies_VERSIONS}") +string(REPLACE ";" "\n" NF_NativeAssemblies_CSV "${NF_NativeAssemblies_VERSIONS}")
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (10)
- .editorconfig (1 hunks)
- CMake/Modules/FindNF_NativeAssemblies.cmake (6 hunks)
- spelling_exclusion.dic (1 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsOptions.cs (3 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.cs (3 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/Interop/nanoCLR.cs (2 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs (2 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs (1 hunks)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (2 hunks)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.h (3 hunks)
Files skipped from review due to trivial changes (1)
- spelling_exclusion.dic
Additional comments not posted (14)
targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsOptions.cs (3)
1-2: LGTM: Updated copyright noticeThe copyright notice has been appropriately updated to reflect the MIT license. This change aligns with standard open-source practices and ensures proper attribution.
19-23: LGTM: New property for retrieving native assemblies informationThe
GetNativeAssembliesproperty has been correctly implemented as a boolean option. Its purpose aligns with the PR objectives of allowing users to obtain a list of native assemblies directly from the runtime. TheOptionattribute is properly configured with clear help text.
Line range hint
1-51: Summary: Changes align well with PR objectivesThe modifications to
ClrInstanceOperationsOptions.cssuccessfully implement the new features described in the PR objectives. The addition ofGetNativeAssembliesandLocalInstanceproperties enhances the CLI's capabilities, allowing users to retrieve native assembly information and specify local runtime instances.These changes contribute to the "controlled update" strategy mentioned in the PR summary by providing more flexibility and information to users. The implementation is clean, well-documented, and consistent with the existing code style.
targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.h (2)
Line range hint
1-69: Existing code structure looks goodThe file is well-organized with proper include guards, API export macros, and clear function declarations. The existing code follows good C++ practices and provides a comprehensive API for the nanoCLR.
Line range hint
1-72: Overall, the changes look good and align with PR objectivesThe additions to
nanoCLR_native.hprovide the necessary API extensions for accessing native assembly metadata, as described in the PR objectives. The new function declarations are consistent with the existing code style and integrate well with the current API.Consider implementing the suggested improvements for documentation and error handling to enhance the API's usability and robustness.
targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs (3)
1-2: LGTM: Updated license headerThe license header has been appropriately updated to use the MIT license, which is clear and concise. This change aligns well with open-source best practices.
9-12: LGTM: Reordered using directivesThe using directives have been slightly reordered. This change doesn't affect functionality and may improve code organization and readability.
Line range hint
1-140: Overall assessment: Enhancements align with PR objectivesThe changes to
NanoClrHostBuilder.cssuccessfully implement the new functionality for accessing native assembly details. The code modifications are well-structured, use modern C# features, and align with the PR objectives of providing easy access to metadata of native assemblies in a firmware package.The new
GetNativeAssemblies()method enhances thenanoCLRHostBuilderclass by allowing users to retrieve native assembly details directly. This addition supports the "controlled update" strategy mentioned in the PR objectives.The code changes maintain good coding practices and the overall structure of the file. The minor improvements to the license header and using directives contribute to better code organization.
targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (2)
186-189: LGTM: Simple and effective implementation.The function
nanoCLR_GetNativeAssemblyCountprovides a clean way to access the count of native assemblies. The use ofuint16_tis appropriate for the expected range of assembly counts.
185-217: Overall, the changes align well with the PR objectives.The new functions
nanoCLR_GetNativeAssemblyCountandnanoCLR_GetNativeAssemblyInformationprovide the necessary functionality to access metadata of native assemblies in the firmware package. This aligns with the PR's goal of facilitating a "controlled update" strategy for nanoFramework.While the implementations are generally sound, consider the suggested improvements for
nanoCLR_GetNativeAssemblyInformationto enhance safety and efficiency.These additions will enable the runtime to provide information about native assemblies, supporting the new
--getnativeassembliesoption mentioned in the PR objectives.targets/netcore/nanoFramework.nanoCLR.Host/Interop/nanoCLR.cs (1)
93-94: LGTM: New method for retrieving native assembly count.The
nanoCLR_GetNativeAssemblyCountmethod is well-defined and consistent with the existing code style. The use ofushortas the return type is appropriate for counting assemblies.targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs (1)
94-94: Verify the encoding used for assembly namesIn the constructor,
GetZeroTerminatedStringis called withtrueforfUTF8, assuming the assembly names are UTF-8 encoded. Confirm that the runtime indeed provides names in UTF-8 encoding to prevent potential misinterpretation of the assembly names..editorconfig (1)
179-179: Confirm the license header templateThe
file_header_templateis set to the .NET Foundation's license. Please verify that this reflects the correct licensing for the nanoFramework project. If a different license applies, update the template accordingly to ensure proper attribution.CMake/Modules/FindNF_NativeAssemblies.cmake (1)
230-232: Verify Existence of Core Library Source FilesWhen adding versions for always-included assemblies, ensure that the specified source files exist to prevent file read errors.
Run the following script to confirm the source files are present:
Verification successful
Core Library Source Files Exist
Both
corlib_native.cppandnf_rt_native.cppwere found in the repository at their expected locations.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that core library source files exist. # Expected: Both files should exist. files=( "${CMAKE_SOURCE_DIR}/src/CLR/CorLib/corlib_native.cpp" "${CMAKE_SOURCE_DIR}/src/nanoFramework.Runtime.Native/nf_rt_native.cpp" ) for file in "${files[@]}"; do if [ ! -f "$file" ]; then echo "Error: $file not found." else echo "Found: $file" fi doneLength of output: 571
Script:
#!/bin/bash # Description: Search for the missing core library source files in the repository. fd "corlib_native.cpp" . fd "nf_rt_native.cpp" .Length of output: 135
targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs
Outdated
Show resolved
Hide resolved
Automated fixes for code style.
…d90-142b-4847-aa77-bf3e8370fb56 Code style fixes for nanoframework/nf-interpreter PR#3023
There was a problem hiding this comment.
Actionable comments posted: 4
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (6)
- CMake/Modules/FindNF_NativeAssemblies.cmake (6 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.cs (3 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/Interop/nanoCLR.cs (2 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs (2 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs (1 hunks)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (2 hunks)
Files skipped from review as they are similar to previous changes (5)
- targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.cs
- targets/netcore/nanoFramework.nanoCLR.Host/Interop/nanoCLR.cs
- targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs
- targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp
Additional comments not posted (1)
CMake/Modules/FindNF_NativeAssemblies.cmake (1)
135-140: LGTM: Correctly integrated AddNativeAssemblyVersionThe addition of the
AddNativeAssemblyVersioncall in thePerformSettingsForApiEntrymacro is correct and well-integrated. This change ensures that the version information for each API is properly collected.
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
CMake/Modules/FindNF_NativeAssemblies.cmake (1)
486-491: LGTM: CSV file creation with native assembly versionsThe implementation for creating the CSV file with native assembly versions is well done. It correctly formats the content and includes appropriate error handling for the file write operation.
A minor suggestion for improvement:
Consider adding a status message when the file is successfully written, to provide positive feedback in addition to the warning for failure.You could add a success message like this:
if(WRITE_RESULT EQUAL 0) message(STATUS "Successfully wrote native_assemblies.csv file") else() message(WARNING "Failed to write native_assemblies.csv file") endif()
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- CMake/Modules/FindNF_NativeAssemblies.cmake (6 hunks)
Additional context used
Learnings (1)
CMake/Modules/FindNF_NativeAssemblies.cmake (3)
Learnt from: frobijn PR: nanoframework/nf-interpreter#3023 File: CMake/Modules/FindNF_NativeAssemblies.cmake:95-106 Timestamp: 2024-09-23T17:56:37.570Z Learning: The `AddCorLibAssemblyVersion` macro in `CMake/Modules/FindNF_NativeAssemblies.cmake` does not require additional error handling for regex failures because the associated *.cpp files contain warnings against modification. Any changes to these files should be accompanied by corresponding updates to the CMake file.Learnt from: frobijn PR: nanoframework/nf-interpreter#3023 File: CMake/Modules/FindNF_NativeAssemblies.cmake:88-109 Timestamp: 2024-09-23T17:59:04.080Z Learning: In `CMake/Modules/FindNF_NativeAssemblies.cmake`, when similar macros like `AddNativeAssemblyVersion` and `AddCorLibAssemblyVersion` have different logic, prefer keeping them separate to maintain readability rather than refactoring into a shared function.Learnt from: frobijn PR: nanoframework/nf-interpreter#3023 File: CMake/Modules/FindNF_NativeAssemblies.cmake:74-79 Timestamp: 2024-09-23T17:56:30.234Z Learning: In the `AddNativeAssemblyVersion` macro, error handling for missing version information may not be necessary because the version format is generated and errors are unlikely. Additionally, native components not related to managed components may not need their native assembly metadata added to the list.
Additional comments not posted (4)
CMake/Modules/FindNF_NativeAssemblies.cmake (4)
67-83: LGTM: AddNativeAssemblyVersion macro implementationThe
AddNativeAssemblyVersionmacro is well-implemented. It correctly extracts the version information from the native assembly source files using a complex but accurate regex pattern. The extracted information is then appropriately appended to theNF_NativeAssemblies_VERSIONSlist.
88-109: LGTM: AddCorLibAssemblyVersion macro implementationThe
AddCorLibAssemblyVersionmacro is well-implemented. It correctly handles the special case of the CorLib assembly, including:
- Using a more complex regex pattern to capture two checksums.
- Implementing conditional logic based on the
NF_FEATURE_SUPPORT_REFLECTIONflag.The implementation aligns with the project's requirements and previous learnings regarding error handling.
139-140: LGTM: Integration of AddNativeAssemblyVersion in PerformSettingsForApiEntryThe modification to the
PerformSettingsForApiEntrymacro correctly integrates the newAddNativeAssemblyVersionmacro. The parameters passed are accurate and consistent with theAddNativeAssemblyVersiondefinition, ensuring that the version information for each API is properly added to the list.
175-176: LGTM: Integration of AddNativeAssemblyVersion in PerformSettingsForInteropEntryThe modification to the
PerformSettingsForInteropEntrymacro correctly integrates the newAddNativeAssemblyVersionmacro. The parameters passed are accurate and consistent with theAddNativeAssemblyVersiondefinition, ensuring that the version information for each Interop assembly is properly added to the list.
targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs
Outdated
Show resolved
Hide resolved
targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs
Outdated
Show resolved
Hide resolved
targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs
Outdated
Show resolved
Hide resolved
targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs
Outdated
Show resolved
Hide resolved
targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs
Outdated
Show resolved
Hide resolved
|
Fixed the description sections to follow PR template. |
What was the problem? I stared at it for some time but didn't see what the issue was. |
There was a problem hiding this comment.
I'm not a big fan of the new option to list the assemblies... 🤔
This is a deviation from all the other CLRs (on which this data is already possible to request) which makes it necessary to process it differently when connected to the virtual device and when connected to hardware.
Seems like a very very niche usage scenario that complicates the usage of, just because it deviates...
| @@ -38,6 +42,14 @@ public class ClrInstanceOperationsOptions | |||
| HelpText = "Specify a version of nanoCRL to install.")] | |||
| public string TargetVersion { get; set; } | |||
|
|
|||
| [Option( | |||
There was a problem hiding this comment.
This is a duplication of ExecuteCommandLineOptions.LocalInstance`, isn't it?
There was a problem hiding this comment.
Yes and no. It serves the same purpose. But the way the options are organised is per "verb", so per "instance" and "run", so a new option has to be introduced.
My choice was to name it differently than the LocalInstance option for "run", as the LocalInstance is quite tricky. The LocalInstance option is described as the specification of a file that should be used as runtime. But if you try that as a simple user and pass "\nanoclr-1.2.3.dll", that won't work. Nanoclr uses the directory of the path and always uses the file name "nanoFramework.nanoCLR.dll". There are good reasons for that if you look at the code, but as a user (at least for me) it was a surprise. Because of backward compatibility the existing LocalInstance should not be changed, but I decided to give the new option a better name, let the user pass the directory and mention in the description that the file name is fixed.
There was a problem hiding this comment.
Understood on the potential confusion about the path + name. That can be easily fixed, of course.
Now about the verbs, those are organized in that manner on purpose.
The CLI at the end of the day acts as a loader for a CLR instance. That's why you find the localinstance option under the run verb. Because one is requesting the tool to RUN that CLR instance (in lieu of the default one).
You're proposing to move this to the INSTANCE verb. That is not logical because, at that point of the execution its already running THAT instance that was previously requested. All this works perfectly garbled and mixed anyway considering that the CLI options are parsed and only after that the thing will actually do something.
Still, I would prefer to keep the consistency and have the options where they belong.
All for improving the option help text, documentation and code that processes it to simplify.
No strong opinion on allowing a DLL name different than nanoFramework.nanoCLR.dll... if that seems important... this was more a like an extra validation and using the default name seemed like a good approach to make the user life easier.
There was a problem hiding this comment.
You're proposing to move this to the INSTANCE verb
No, not to move. Both verbs need this option:
-
If you have a runtime (dll) and want to know the native assemblies, there is no other way than to use "nanoclr.exe instance" that already provides information about the runtime and has the option to update the runtime. Either that or you create a separate tool for that.
-
If you want to use the runtime to run assemblies, you'd use the "nanoclr.exe run". This is also used by the test framework.
The way the CLI program is organized, there is no way to have common options. So I think the choices are: use the same name for both verbs (to stress that it is both concern the runtime DLL) or allow different names and use that to make one option a bit more clear.
No strong opinion on allowing a DLL name different than nanoFramework.nanoCLR.dll..
Maybe I don't understand how the various components work together, but I thought that the runtime DLL is the same one that is referred to by the various DLLImport declarations in the managed nanoFramework.nanoCLR.Host assembly. AFAIK if the DLL is a native DLL, the name used in the DLLImport must match the name of the DLL.
BTW I don't want to use a different file name, but the option suggests that it is possible. Put me on the wrong track.
There was a problem hiding this comment.
Absolutely correct on that last part (I overlooked that) it must have that name because of the DLL import declarations as you've pointed out.
Actually it is worse than that. There are three ways a runtime is packaged:
The last version is hidden in an auto-update scenario, as it is only used by "nanoclr instance --update". But if you want to freeze the framework version, I think you need to make a backup of that as well. On the upside: all this information is required for tooling that runs at build-time. Once that tooling is part of the framework, I don't think that there are (m)any users that have a use case for retrieving the native assemblies. Then a new command line option that probably no human uses doesn't seem to be a bad solution. |
…s built. This is done by CMake that reads the data in the source files. The native_assemblies.csv file lists name, version and checksum for the included native assemblies. - Extra options --getnativeassemblies and --clrinstancepath added to nanoclr.exe (and corresponding code to the native CLR host). This produces a list of name, version and checksum for the native assemblies included in the runtime embedded in nanoclr.exe or external file. Can still be used with "old" runtimes. - .editorconfig added It would be great if the latest version of each firmware package on cloudsmith would be re-created (with the same version number) so that the `native_assemblies.csv` files are part of the packages. I have no idea how to make that happen. Signed-off-by: Frank Robijn <robijn@good-heavens.nl>
- Rename and adjust LocalInstance option to improve description. - Add code to make sure DLL path is correct.
- Extract method to keep main method cleaner. - Output is shown in a tidy 3 column table style to make it more visually attractive. - Add exit code with warning about the fact that native assembly list can't be retrieved.
josesimoes
force-pushed
the
Versioning
branch
from
2284649 to
132e84d
Compare
|
@frobijn I've made some improvements on the code and pushed to the PR.
Please review! |
josesimoes
changed the title
josesimoes
added
the
Platform: Virtual Device & WIN32
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (10)
targets/netcore/nanoFramework.nanoCLR.CLI/CommonOptions.cs (3)
8-15: Consider making the property setter private.The
PathToCLRInstanceproperty is well-defined with appropriateOptionattribute settings. However, to enhance encapsulation, consider making the setter private:-public string PathToCLRInstance { get; set; } +public string PathToCLRInstance { get; private set; }This change would prevent external code from modifying the property after it's set by the command-line parser, ensuring better control over the property's state.
17-31: Consider using an enum for verbosity levels.The
Verbosityproperty is well-defined with appropriateOptionattribute settings and helpful comments. To improve type safety and validation, consider using an enum for verbosity levels:public enum VerbosityLevel { Quiet, Minimal, Normal, Detailed, Diagnostic } [Option( 'v', "verbosity", Required = false, Default = VerbosityLevel.Normal, HelpText = "Sets the verbosity level of the command. Allowed values are Quiet, Minimal, Normal, Detailed, and Diagnostic. Not supported in every command; see specific command page to determine if this option is available.")] public VerbosityLevel Verbosity { get; private set; }This change would provide stronger typing and built-in validation for the verbosity levels. You may need to implement a custom type converter for the CommandLine parser to handle the enum values.
8-33: Consider making the class sealed.The
CommonOptionsclass is well-structured and focused on its purpose of encapsulating common CLI options. To prevent unintended inheritance and potentially improve performance, consider making the class sealed:-public class CommonOptions +public sealed class CommonOptionsThis change ensures that the class cannot be inherited, which aligns with its purpose as a container for CLI options and may allow for compiler optimizations.
Overall, the implementation is clean, consistent, and follows good practices for command-line option handling.
targets/netcore/nanoFramework.nanoCLR.CLI/ExecuteCommandLineOptions.cs (1)
Line range hint
17-115: Approve remaining options with a minor suggestion.The command-line options are comprehensive and well-documented, covering various aspects of nanoCLR functionality. They align well with the PR objectives of enhancing the CLI capabilities.
For consistency, consider adding a short name (single letter) option for the
waitfordebugger,loopafterexit,forcegc, andcompactionaftergcoptions. This would make them consistent with other options that have both short and long forms.Example:
[Option( - "waitfordebugger", + 'w', + "waitfordebugger", Required = false, Default = false, HelpText = "Option to wait for a debugger connection after nanoCLR is started.")] public bool WaitForDebugger { get; set; }targets/netcore/nanoFramework.nanoCLR.CLI/ExecuteCommandProcessor.cs (2)
28-28: Approve the change with a minor suggestion.The change from
options.LocalInstancetooptions.PathToCLRInstanceis an improvement, as it more accurately describes the purpose of the variable. This aligns well with the new--clrinstancepathoption mentioned in the PR objectives.Consider using camelCase for the variable name to follow C# naming conventions:
-if (options.PathToCLRInstance != null) +if (options.pathToClrInstance != null)
28-36: Summary of changes and areas needing attentionThe modifications in this file implement the new
--clrinstancepathoption mentioned in the PR objectives. The changes look good overall, but there are a few points that require clarification:
- The shift from treating the path as a file to a directory (changing from
File.ExiststoDirectory.Exists).- The implications of passing only the directory name to
nanoCLRHost.CreateBuilder.- Potential backwards compatibility concerns with these changes.
Please address the questions raised in the previous comments to ensure that these changes are fully understood and don't introduce any unintended side effects.
Consider adding comments in the code to explain the rationale behind these changes, especially the switch to using a directory path instead of a file path. This will help future maintainers understand the design decisions made here.
targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (1)
185-225: Overall assessment: Valuable addition with room for improvementThe introduced functions,
nanoCLR_GetNativeAssemblyCountandnanoCLR_GetNativeAssemblyInformation, align well with the PR objectives of providing easy access to metadata of native assemblies. These additions contribute significantly to the "controlled update" strategy mentioned in the PR description.While
nanoCLR_GetNativeAssemblyCountis straightforward and well-implemented,nanoCLR_GetNativeAssemblyInformationcould benefit from the suggested improvements to enhance its robustness, efficiency, and safety.These changes lay a solid foundation for tooling that operates at build-time, as mentioned in the PR comments. However, consider the concerns raised about the efficiency of this approach compared to reading from standard output, especially for virtual device scenarios. It might be worth exploring alternative methods or optimizations to address these concerns in future iterations.
targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.cs (3)
25-47: LGTM! Consider enhancing error messages.The new conditional structure for handling local CLR instances is well-implemented. It properly checks for conflicting options and directory existence before creating the
nanoCLRHostBuilder.Consider enhancing the error messages in the
CLIExceptionthrows:- throw new CLIException(ExitCode.E9010); + throw new CLIException(ExitCode.E9010, "Cannot combine PathToCLRInstance and UpdateCLR options."); - throw new CLIException(ExitCode.E9009); + throw new CLIException(ExitCode.E9009, $"Directory not found: {options.PathToCLRInstance}");This would provide more context to the user about the specific error encountered.
57-86: LGTM! Consider extracting method for better readability.The new conditional structure for handling CLR version and native assemblies output is well-implemented. It properly handles different verbosity levels and formats the output clearly.
Consider extracting the logic for outputting CLR version and native assemblies into a separate method for better readability:
private static void OutputClrAndAssemblyInfo(ClrInstanceOperationsOptions options, nanoCLRHostBuilder hostBuilder) { if (Program.VerbosityLevel > VerbosityLevel.Normal) { hostBuilder.OutputNanoClrDllInfo(); } if (options.GetCLRVersion) { Console.WriteLine($"nanoCLR version: {hostBuilder.GetCLRVersion()}"); } if (options.GetNativeAssemblies) { OutputNativeAssembliesInfo(hostBuilder, options.GetCLRVersion); } } private static void OutputNativeAssembliesInfo(nanoCLRHostBuilder hostBuilder, bool clrVersionOutputted) { List<NativeAssemblyDetails>? nativeAssemblies = hostBuilder.GetNativeAssemblies(); if (nativeAssemblies is not null) { if (clrVersionOutputted) { Console.WriteLine(); } OutputNativeAssembliesList(nativeAssemblies); } else if (Program.VerbosityLevel > VerbosityLevel.Normal) { Console.WriteLine("Unable to retrieve native assemblies information."); } }Then, you can replace the existing code with:
else if (options.GetCLRVersion || options.GetNativeAssemblies) { OutputClrAndAssemblyInfo(options, hostBuilder); return (int)ExitCode.OK; }This refactoring improves code readability and maintainability by separating concerns.
94-106: LGTM! Consider minor performance optimization.The
OutputNativeAssembliesListmethod is well-implemented, providing a neatly formatted output of native assembly details. The use of LINQ for calculating padding is efficient and results in a clean, readable output.For a minor performance optimization, consider calculating the maximum lengths in a single pass:
private static void OutputNativeAssembliesList(List<NativeAssemblyDetails> nativeAssemblies) { Console.WriteLine("Native assemblies:"); int maxAssemblyNameLength = 0; int maxAssemblyVersionLength = 0; foreach (var assembly in nativeAssemblies) { maxAssemblyNameLength = Math.Max(maxAssemblyNameLength, assembly.Name.Length); maxAssemblyVersionLength = Math.Max(maxAssemblyVersionLength, assembly.Version.ToString().Length); } foreach (NativeAssemblyDetails assembly in nativeAssemblies) { Console.WriteLine($" {assembly.Name.PadRight(maxAssemblyNameLength)} v{assembly.Version.ToString().PadRight(maxAssemblyVersionLength)} 0x{assembly.CheckSum:X8}"); } }This approach avoids multiple iterations over the list and might be more efficient for larger lists of assemblies.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (14)
- .editorconfig (1 hunks)
- CMake/Modules/FindNF_NativeAssemblies.cmake (6 hunks)
- spelling_exclusion.dic (1 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsOptions.cs (2 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.cs (3 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/CommonOptions.cs (1 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ExecuteCommandLineOptions.cs (1 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ExecuteCommandProcessor.cs (2 hunks)
- targets/netcore/nanoFramework.nanoCLR.CLI/ExitCode.cs (1 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/Interop/nanoCLR.cs (3 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs (2 hunks)
- targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs (1 hunks)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (2 hunks)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.h (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (8)
- .editorconfig
- CMake/Modules/FindNF_NativeAssemblies.cmake
- spelling_exclusion.dic
- targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsOptions.cs
- targets/netcore/nanoFramework.nanoCLR.Host/Interop/nanoCLR.cs
- targets/netcore/nanoFramework.nanoCLR.Host/NanoClrHostBuilder.cs
- targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.h
🔇 Additional comments not posted (10)
targets/netcore/nanoFramework.nanoCLR.CLI/CommonOptions.cs (1)
1-7: LGTM: Proper license and namespace declaration.The file includes the appropriate license information and correctly declares the namespace. The import statement for the
CommandLinenamespace is also present, which is necessary for theOptionattributes used in the class.targets/netcore/nanoFramework.nanoCLR.CLI/ExecuteCommandLineOptions.cs (1)
Line range hint
1-115: Overall assessment: Positive changes that enhance CLI functionality.The modifications to
ExecuteCommandLineOptions.csalign well with the PR objectives. The inheritance change improves code organization, and the remaining options provide comprehensive control over the nanoCLR CLI. These changes contribute to the goal of facilitating a "controlled update" strategy for the nanoFramework.targets/netcore/nanoFramework.nanoCLR.CLI/ExitCode.cs (3)
109-114: LGTM: New enum valueE9010is well-defined and consistent.The new enum value
E9010is correctly implemented with a clear summary comment and display name. It aligns with the PR objectives by addressing the scenario where a CLR instance update is attempted when a specific version is requested.
116-120: LGTM: New enum valueE9011is well-defined and consistent.The new enum value
E9011is correctly implemented with a clear summary comment and display name. It aligns with the PR objectives by addressing the scenario where the list of native assemblies cannot be retrieved.
109-120: Overall changes to ExitCode enum are consistent and well-implemented.The two new enum values,
E9010andE9011, have been added correctly to theExitCodeenum. They follow the existing naming conventions and numbering pattern. The additions are consistent with the PR objectives and provide clear error codes for the new features related to CLR instance updates and native assembly list retrieval.targets/netcore/nanoFramework.nanoCLR.CLI/ExecuteCommandProcessor.cs (2)
31-31: Clarify the change from file to directory check.The change from
File.ExiststoDirectory.Existssuggests thatPathToCLRInstancenow represents a directory path rather than a file path. This is a significant change that may affect how the CLR instance is loaded.Could you please clarify:
- Why was this change made?
- How does this affect the loading of the CLR instance?
- Are there any backwards compatibility concerns?
To verify the impact of this change, please run the following script:
✅ Verification successful
Change from
File.ExiststoDirectory.ExistsVerifiedThe update to use
Directory.ExistsforPathToCLRInstanceis consistent across the codebase. No instances ofFile.Existsrelated toPathToCLRInstancewere found, ensuring that it is correctly treated as a directory path.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other occurrences of File.Exists or Directory.Exists related to CLR instance loading # Test: Search for File.Exists and Directory.Exists usage echo "Searching for File.Exists usage:" rg --type csharp "File\.Exists.*Instance" -A 5 echo "Searching for Directory.Exists usage:" rg --type csharp "Directory\.Exists.*Instance" -A 5Length of output: 1663
36-36: Approve the change with a request for additional information.The modification to use
Path.GetDirectoryName(options.PathToCLRInstance)is consistent with the earlier changes and ensures that only the directory path is passed tonanoCLRHost.CreateBuilder.To ensure this change doesn't introduce any unintended side effects:
- Could you explain how
nanoCLRHost.CreateBuilderuses this directory path?- Are there any scenarios where passing only the directory name might cause issues?
Please run the following script to verify the usage of
CreateBuilder:targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (1)
186-189: LGTM: Simple and straightforward implementation.The function
nanoCLR_GetNativeAssemblyCountcorrectly returns the count of native assemblies using the global variableg_CLR_InteropAssembliesCount. The implementation is concise and appropriate for this task.targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.cs (2)
7-7: LGTM! Necessary addition for LINQ operations.The addition of
using System.Linq;is appropriate and necessary for the LINQ operations used in theOutputNativeAssembliesListmethod.
11-12: LGTM! Verify Newtonsoft.Json usage.The addition of
using nanoFramework.nanoCLR.Host;andusing Newtonsoft.Json;statements is appropriate for the new functionality in this file.Let's verify the usage of Newtonsoft.Json in this file:
This will help ensure that Newtonsoft.Json is being used as expected in the file.
✅ Verification successful
Verified Newtonsoft.Json usage.
The usage of
JsonConvert.DeserializeObject<List<CloudsmithPackageInfo>>(responseBody);inClrInstanceOperationsProcessor.cscorrectly implements JSON deserialization as intended.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify Newtonsoft.Json usage in ClrInstanceOperationsProcessor.cs # Test: Search for Newtonsoft.Json usage rg --type csharp 'JsonConvert' targets/netcore/nanoFramework.nanoCLR.CLI/ClrInstanceOperationsProcessor.csLength of output: 214
- Required to offer a smooth migration path to developers and tools currently using this option. - Marked as Obsolete.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
targets/netcore/nanoFramework.nanoCLR.CLI/CommonOptions.cs (2)
18-31: LGTM: Well-handled deprecation of LocalInstanceThe
LocalInstanceproperty is correctly marked as obsolete and hidden, maintaining backward compatibility while encouraging the use of the newPathToCLRInstanceproperty. The setter logic ensures that values are still captured correctly.Consider updating the obsolete message to include the new option name:
-[Obsolete("This option is deprecated and will be removed in a future version. Use --clrpath instead.")] +[Obsolete("This option is deprecated and will be removed in a future version. Use --clrpath instead of --localinstance.")]
34-48: LGTM: Well-implemented Verbosity propertyThe
Verbosityproperty is well-implemented with clear documentation, appropriate CommandLine attributes, and comprehensive help text. The use of both short and long option names enhances usability.For consistency with the other properties, consider moving the XML documentation to the property itself:
- /// <summary> - /// Allowed values: - /// q[uiet] - /// m[inimal] - /// n[ormal] - /// d[etailed] - /// diag[nostic] - /// </summary> [Option( 'v', "verbosity", Required = false, Default = "n", HelpText = "Sets the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. Not supported in every command; see specific command page to determine if this option is available.")] + /// <summary> + /// Sets the verbosity level of the command. + /// Allowed values: + /// q[uiet], m[inimal], n[ormal], d[etailed], diag[nostic] + /// </summary> public string Verbosity { get; set; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- targets/netcore/nanoFramework.nanoCLR.CLI/CommonOptions.cs (1 hunks)
🔇 Additional comments not posted (2)
targets/netcore/nanoFramework.nanoCLR.CLI/CommonOptions.cs (2)
11-16: LGTM: Well-defined property for CLR pathThe
PathToCLRInstanceproperty is well-implemented with clear naming and appropriate CommandLine attributes. The help text effectively explains its purpose.
1-50: LGTM: Well-structured CommonOptions classThe
CommonOptionsclass is well-implemented, providing a clean and effective way to handle common command-line options for the nanoFramework CLI. It makes good use of the CommandLine library for robust option parsing and effectively manages the deprecation of an old option while introducing a new one.The class structure and property implementations follow good practices, enhancing usability and maintainability of the CLI interface.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs (1 hunks)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (2 hunks)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.h (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- targets/netcore/nanoFramework.nanoCLR.Host/NativeAssemblyDetails.cs
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.h
🧰 Additional context used
📓 Learnings (1)
targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (1)
Learnt from: josesimoes PR: nanoframework/nf-interpreter#3023 File: targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp:191-225 Timestamp: 2024-09-25T11:28:38.536Z Learning: When working with `nanoCLR_GetNativeAssemblyInformation`, fixed-size assembly names are required, so code that deals with variable-length names cannot be used.
🔇 Additional comments not posted (1)
targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (1)
186-189: LGTM: Simple and correct implementation.The
nanoCLR_GetNativeAssemblyCountfunction is implemented correctly. It returns the value ofg_CLR_InteropAssembliesCountas auint16_t, which should be sufficient for the number of native assemblies.
Co-authored-by: Laurent Ellerbach <laurelle@microsoft.com>
…verified & bug fixed.
Automated fixes for code style.
|
Nice presentation! I've added a sort by name to make it even more readable. Checked the replacement of the LocalInstance by PathToClrInstance option (few changes) and tested it. Works well. |
…0ad-0310-4956-bd59-f669b6f7d3a9 Code style fixes for nanoframework/nf-interpreter PR#3023
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (1)
191-231: LGTM: Well-implemented function with proper checks.The
nanoCLR_GetNativeAssemblyInformationfunction is well-implemented with appropriate null checks and buffer size validation. It efficiently copies native assembly information into the provided buffer.A minor suggestion for improvement:
Consider using a constant for the fixed assembly name size (128 bytes) to improve maintainability. For example:
const size_t ASSEMBLY_NAME_SIZE = 128; // Update the requiredSize calculation const size_t requiredSize = g_CLR_InteropAssembliesCount * (5 * sizeof(CLR_UINT16) + ASSEMBLY_NAME_SIZE); // ... and later in the code ... hal_strcpy_s((char *)data, ASSEMBLY_NAME_SIZE, g_CLR_InteropAssembliesNativeData[i]->m_szAssemblyName); data += ASSEMBLY_NAME_SIZE;This change would make it easier to adjust the size in the future if needed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (2 hunks)
🔇 Additional comments (1)
targets/netcore/nanoFramework.nanoCLR/nanoCLR_native.cpp (1)
186-189: LGTM: Simple and effective implementation.The
nanoCLR_GetNativeAssemblyCountfunction is well-implemented. It directly returns theg_CLR_InteropAssembliesCount, which is appropriate for retrieving the count of native assemblies. The use ofuint16_tas the return type is suitable, assuming the number of native assemblies will never exceed 65535.
|
@frobijn thank you again for your contribution! 🙏😄 .NET nanoFramework is all about community involvement, and no contribution is too small. Please edit it and add an entry with your GitHub username in the appropriate location (names are sorted alphabetically): (Feel free to adjust your name if it's not correct) |
|
@frobijn to answer your question above: there is no easy way to recreate the published fw pacakges. That would require a lot of manual work. From now on that will be there. |
Description
A file native_assemblies.csv is generated when a firmware package is built. This is done by CMake that reads the data in the source files. The native_assemblies.csv file lists name, version and checksum for the included native assemblies.
New option --getnativeassemblies added to nanoclr.exe (and corresponding code to the native CLR host). This produces a list of name, version and checksum for the native assemblies included in the runtime embedded in nanoclr.exe or external file. Can still be used with "old" runtimes.
Rename
--localinstanceto--clrpathand made it common to reuse on all verbs.It would be great if the latest version of each firmware package on cloudsmith would be re-created (with the same version number) so that the
native_assemblies.csvfiles are part of the packages. I have no idea how to make that happen.Motivation and Context
This is a PR related to the "controlled update" strategy as alternative for the current nanoFramework's "auto-update" strategy. It is required for the "controlled update" strategy to work, but there are no other PR dependent on this PR. All other software changes can be made and tested independent of this PR.
For a description of how the "controlled update" strategy would work, see the concept documentation in my fork.
For a description of all related changes required to make the "controlled update" strategy work, see a detailed description in another fork.
Long description
The changes in this repository have been made to get a list of names and versions of the native assemblies that are used in a runtime, without having to connect to a device via a serial port and retrieve the list via the wire protocol.
NanoCLR.exe: an option has been added: --getnativeassemblies, similar to (and can be combined with) --getversion. The result is a list of names, version and checksums sent to the standard output.
It calls a method in the CLR host assembly to get information about the native assemblies (a .NET class). The data for that class is deserialized from data obtained via two additional methods in the native NanoCLR runtime that serializes the static constants in the runtime with native assembly information. If a tool requires the list of native assemblies, it can run the nanoclr.exe and parse its output.
NanoCLR.exe: added --clrinstancepath to use with --getnativeassemblies, so that the above keeps working if nanoclr.exe is updated but an older runtime is used. If the instance does not support the two additional methods in the native NanoCLR runtime, no details about the native assemblies is displayed, but instead a message (if verbosity is high enough).
NanoCLR.exe: changes have been tested by running the tool, for the "embedded" runtime, the same runtime via --clrinstancepath, and the current version of the runtime (from Cloudsmith) via --clrinstancepath.
CMake/Modules/FindNF_NativeAssemblies.cmake: create a
native_assemblies.csvfile in the build output directory of a firmware package that contains the names, version and checksums of the native assemblies selected to be part of the firmware.The CMake code to extract version and checksum works well for the native assemblies that use the skeleton generated by the metadata processor. There are two native assemblies that define the checksum in a different way:
File creation has been tested for a few firmware packages. As there does not seem to be a target with
NF_FEATURE_SUPPORT_REFLECTION = OFF, that part of the CMake script could not be tested. The CMake regex has been tested by temporarily using it for theNF_FEATURE_SUPPORT_REFLECTION = ONcase.As .csv files are copied to the firmware .zip package, it is assumed the
native_assemblies.csvwill become part of the firmware package. This is not tested.Added .editorconfig.
How Has This Been Tested?
See long description.
Types of changes
Checklist
Summary by CodeRabbit
Release Notes
New Features
.editorconfigfile to enforce consistent coding styles across the project.ClrInstanceOperationsOptionsfor retrieving native assembly details and specifying local instances.NativeAssemblyDetailshas been introduced to encapsulate information about native assemblies.Bug Fixes
Documentation
Chores