Skip to content

Improve CSharp Examples #8562

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Conversation

gojimmypi
Copy link
Contributor

@gojimmypi gojimmypi commented Mar 14, 2025

Description

Updates C# Wrapper examples, adds features to wolfSSL C# wrapper, fixes Windows build-time warnings, revised code for compatibility with older frameworks missing language and library features otherwise found in recent versions..

  • edit: I've put together a blog to help explain in more detail the DLL challenges encountered in Visual Studio (and Windows in General), as well as the value of having the new App.config settings: WOLFSSL_DLL_PATH and WOLFSSL_CERTS_PATH.

See: https://gojimmypi.github.io/Using-wolfssl-in-Visual-Studio/

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
    <appSettings>
        <add key="WOLFSSL_DLL_PATH" value="C:/Windows/System32"/>
        <add key="WOLFSSL_CERTS_PATH" value="C:/workspace/wolfssl/certs"/>
    </appSettings>
</configuration>
  • edit[2]: The enclosed new .github/workflows/visual-studio.yml is intentionally separate from the existing win-csharp-test.yml workflow. This new visual-studio.yml is intended to grow to be repository-wide, checking all the Visual Studio project files everywhere for line endings, file encoding, and check build configurations for projects beyond just the C# wrapper. Actual functional tests are expected to remain in a separate workflow. See the WIP my_visual-studio.yml which is beyond the scope of this PR.

NET 3.5 Compatibility for wolfSSL C# Wrappers

Overview

This PR adds compatibility with .NET Framework 3.5 to the wolfSSL C# wrappers and examples, enabling wolfSSL to be used in environments that require older .NET Framework versions.

Key Changes

Framework Targeting

  • Changed target framework from .NET 4.8 to .NET 3.5 in all C# projects
  • Updated App.config files to use supportedRuntime version="v2.0.50727" instead of v4.0
  • Removed references to newer framework assemblies not available in .NET 3.5 (System.Core, System.Xml.Linq, System.Data.DataSetExtensions)
  • Added System.Configuration reference for configuration management

DLL Import/Export Handling

  • Modified header files ( curve25519.h, ed25519.h) to fix DLL import/export declarations for better compatibility, fixing warning C4141: 'dllexport': used more than once
  • Added cpp.hint file to assist Visual Studio with C++ identifier interpretation
  • Updated wolfSSL.cs with improved DLL path handling for .NET 3.5 environments
  • Updated sniffer.h to not define SSL_SNIFFER_API __declspec(dllexport) unless SSL_SNIFFER_EXPORTS found

Build System

  • Added new GitHub Actions workflow (visual_studio.yml) to test building with .NET 3.5
  • Added new solution file (wolfSSL_CSharp-Clients.sln) specifically for client examples
  • Updated include.am to include new files in distribution

Error Handling and Logging

  • Improved error handling in example applications with proper exit codes
  • Enhanced debug logging with conditional compilation based on build configuration
  • Added configuration settings for DLL and certificate paths in App.config files

Documentation

  • Updated README.md with expanded instructions for Windows and Linux environments
  • Updated copyright information to reflect current year

Benefits

  • Enables wolfSSL to be used in legacy systems that require .NET 3.5
  • Improves compatibility with older Windows environments
  • Provides better error handling and configuration options
  • Adds CI testing for .NET 3.5 builds to prevent regressions

Fixes zd#

Testing

How did you test?

Tested manually on Windows 2022, Visual Studio 2022. See also new workflow (build only) from my visual_studio.yml

Checklist

  • added tests
  • updated/added doxygen
  • updated appropriate READMEs
  • Updated manual and documentation

@@ -2425,23 +2425,27 @@ public static byte[] Curve25519ExportPublicKey(IntPtr key)
return publicKey;
}

/* Tuples not supported in older frameworks such as 3.5 */
/* public static (byte[] privateKey, byte[] publicKey) Curve25519ExportKeyRaw(IntPtr key) */

/// <summary>
/// Export both private and public keys from a Curve25519 key structure
/// </summary>
/// <param name="key">Curve25519 key structure</param>
/// <returns>A tuple containing the private key and public key as byte arrays</returns>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update the returns tags to match the new return type (void).
Maybe we could move the comments at line 2428-2429 directly here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, good catch. updated & removed code that was commented out.

//var configAttr = (AssemblyConfigurationAttribute)Attribute.GetCustomAttribute(
// Assembly.GetExecutingAssembly(), typeof(AssemblyConfigurationAttribute));

//return configAttr?.Configuration ?? "Unknown";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this commented code be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yes, I did not intend to keep the code commented out.

Copy link
Contributor

@gasbytes gasbytes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of minor things that I noticed.

Copy link
Contributor

@gasbytes gasbytes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more minor changes.

Calling ctx Init from wolfSSL
```

Note the `WOLFSSL_DLL` is used in the wolfssl `visibiility.h` and defines the `WOLFSSL_API` like this:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spelling and maybe we could provide the full path to the header file?:
wolfssl/wolfssl/wolfcrypt/visibility.h

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good idea. updated


### Build wolfSSL and install to arbitrary directory

To have a n isolated instance of wolfSSL, in this case `$HOME/wolfssl-install-psk`:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spelling.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, good catch! fixed.

@gojimmypi
Copy link
Contributor Author

Jenkins retest this please.

for Unable to create live FilePath for wolf-linux-cloud-node marked offline: Connection was broken in PRB-dtls.txt_39 from 'PRB-generic-config-parser/7682`

@gojimmypi gojimmypi requested a review from gasbytes March 16, 2025 21:37
@gojimmypi
Copy link
Contributor Author

Jenkins retest this please.

for "Cannot contact wolf-linux-cloud-node"

@dgarske dgarske self-requested a review March 21, 2025 19:43
@dgarske
Copy link
Contributor

dgarske commented Mar 21, 2025

Please resolve merge conflicts

@dgarske dgarske assigned dgarske and unassigned dgarske Mar 31, 2025
@dgarske dgarske removed their request for review April 4, 2025 22:49
@gojimmypi
Copy link
Contributor Author

Jenkins retest this please.

for: "Remote call on wolf-linux-cloud-node-nnn failed. The channel is closing down or has closed down"

@gojimmypi
Copy link
Contributor Author

Hi @dgarske - merge conflicts resolved.

@dgarske
Copy link
Contributor

dgarske commented Apr 8, 2025

Please don't merge this yet. I am not sure if I want to have the VS2005 / .NET 3.5 support introduced this way. I've got a large portion of these changes in #8621 already. The changes made to CSharp for .NET 3.5 should hopefully be backwards compatible. And the actual project files I may want to keep elsewhere.

@gojimmypi gojimmypi marked this pull request as draft April 10, 2025 11:14
@gojimmypi
Copy link
Contributor Author

Marked as draft per @dgarske #8562 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants