Skip to content
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

What's new in .NET 7 RC 2 #7717

Closed
leecow opened this issue Aug 17, 2022 · 7 comments
Closed

What's new in .NET 7 RC 2 #7717

leecow opened this issue Aug 17, 2022 · 7 comments
Assignees

Comments

@leecow
Copy link
Member

leecow commented Aug 17, 2022

What's new in .NET 7 RC 2

This issue is for teams to highlight work for the community that will release .NET 7 RC 2

To add content, use a new conversation entry. The entry should include the team name and feature title as the first line shown in the template below.

## Team Name: Feature title

[link to the tracking issue or epic item for the work]

Tell the story of the feature and anything the community should pay particular attention 
to be successful using the feature.

Preview 1: #7106
Preview 2: #7107
Preview 3: #7108
Preview 4: #7378
Preview 5: #7441
Preview 6: #7454
Preview 7: #7455
RC 1: #7716
RC 2: #7717

@lambdageek
Copy link
Member

lambdageek commented Sep 15, 2022

wasm-experimental: Experimental support for WebAssembly multithreading

dotnet/runtime#68162

The wasm-experimental workload supports multi-threaded .NET apps using JavaScript Web Workers. This support is only implemented for the wasmbrowser template, Blazor apps do not support threading at this time.

Threaded WebAssembly support is experimental in .NET 7 and this is an opportunity for you to provide early feedback on the feature for a future release of .NET.

  • To get started, install .NET 7 RC2 and the wasm-experimental workload:

    dotnet workload install wasm-experimental
    
  • Create a new wasmbrowser app:

    dotnet new wasmbrowser
    
  • The full example below is available at https://github.com/lambdageek/hithread

  • To enable threading, add the WasmEnableThreads property to the project file:

    <PropertyGroup>
     <WasmEnableThreads>true</WasmEnableThreads>
    </PropertyGroup>
  • Optionally if you use platform-guard attributes like SupportedOSPlatform/UnsupportedOSPlatformin your code, add the .NET 7 package feed to your NuGet.config and add a reference to the threading package:

    <!-- in NuGet.config -->
    <configuration>
     <packageSources>
       <add key="dotnet7" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json" />
     </packageSources>
    </configuration>
    <!-- your .csproj -->
    <ItemGroup>
     <PackageReference Include="Microsoft.NET.WebAssembly.Threading" Version="7.0.0-rc.2.*" />
    </ItemGroup>
  • Create and run a new thread.

    using System;
    using System.Threading;
    using System.Runtime.Versioning;
    using System.Runtime.InteropServices.JavaScript;
    
    [assembly:SupportedOSPlatform("browser")]
    
    new Thread(SecondThread).Start();
    Console.WriteLine($"Hello, Browser from the main thread {Thread.CurrentThread.ManagedThreadId}");
    
    static void SecondThread() {
        Console.WriteLine ($"Hello from Thread {Thread.CurrentThread.ManagedThreadId}");
        for (int i = 0; i < 5; ++i) {
    	Console.WriteLine ($"Ping {i}");
            Thread.Sleep (100);
        }
    }
  • build the app and run with the .NET app host

    dotnet build
    dotnet run
    

    or publish and serve the app with another static server such as dotnet-serve. Note that cross origin isolation must be enabled by serving the COOP and COEP headers

    dotnet publish -c Release
    dotnet serve -h "Cross-Origin-Opener-Policy:same-origin" -h "Cross-Origin-Embedder-Policy:require-corp" --directory bin/Release/net7.0/browser-wasm/AppBundle/
    
  • Open the served URL in a browser (note: Chrome, Edge or Safari; at this time Firefox is not supported until Mozilla #1540913 is fixed) open developer tools, and the console should include the following output:

    Hello from Thread 2
    Hello, Browser from the main thread 1
    Ping 0
    Ping 1
    Ping 2
    Ping 3
    Ping 4
    
  • Many properties that control the build such as WasmBuildNative, RunAOTCompilation, WasmEnableSIMD, etc are supported with threading.


Notes and known issues:

  • JSImport and JSExport work from the browser thread, only
  • WebSocket operations are only supported on the main thread
  • A SynchronizationContext is installed on the browser thread by default. If you do not use ConfigureAwait(false) when awaiting asynchronous operations, they will be scheduled on the browser thread. Conversely, not using ConfigureAwait allows your asynchronous operations to return to the browser thread in order to interact with the DOM or other JS libraries that are only available on the main thread.
  • By default the app will create 4 Web Workers that will be used to execute .NET Threads. The runtime will reuse Web Workers to run multiple .NET threads (that is, after one thread stops, the Worker will be pooled and reused for a subsequent Thread.Start call). To control the number of workers that are created at app startup, configure the _WasmPThreadPoolSize property (note the property is experimental and may change in a future release).
    Note that we build the runtime with the Emscripten PTHREAD_POOL_SIZE_STRICT set to 2 (see Emscripten settings.js documentation which means that creating additional workers after the initial pool of workers is exhausted will be a hard error that will stop the app. The maximum parallelism of your app must not exceed the _WasmPThreadPoolSize. Please open an issue in dotnet/runtime if this policy is too restrictive.
  • Debugging multithreaded WASM is not supported yet
  • Threading does not work in Firefox due to Bugzilla #1540913. We currently compile .NET to ES6 modules, which causes Emscripten to use the dynamic import(uri).then(callback) module import that doesn't work in Web Workers in Firefox.

@danmoseley
Copy link
Member

@ericstj @karelz @jeffhandley @eerhardt for any RC2 stuff

@JonDouglas
Copy link
Collaborator

@JeremyLikness @AngelosP FYI

@JonDouglas JonDouglas self-assigned this Sep 19, 2022
@eiriktsarpalis
Copy link
Member

System.Text.Json AppContext switch re-enabling reflection fallback in source generation dotnet/runtime#75615

.NET 7 introduced an intentional breaking change which removes silent fallback to reflection-based serialization in System.Text.Json source generators. Based on early feedback we have been receiving from customers , it appears that quite a few users have (mostly accidentally) taken a dependency on the fallback behavior.

Even though a workaround for the breaking change has been documented, it still requires a code change which might not be possible in certain scenaria. Starting in .NET 7 RC 2, you can re-enable reflection fallback globally using the provided AppContext compatibility switch. Add the following entry to your application's project file to re-enable reflection fallback for all source-generated contexts in your app. For more information on using AppContext switches, see the article on .NET runtime configuration settings.

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Text.Json.Serialization.EnableSourceGenReflectionFallback" Value="true" />
</ItemGroup>

@buyaa-n
Copy link
Contributor

buyaa-n commented Sep 23, 2022

We have added 2 new analyzers for correct usage of new APIs:

  • Implement Generic Math interfaces correctly - Ensures the .NET Generic Math interfaces that uses Curiously Recurring Template Pattern (CRTP) are implemented correctly in user code. In particular it warns if a type that implements the .NET Generic Math interfaces (that implements CRTP pattern) do NOT fill the generic type parameter with the type itself.
    Example:
    public readonly struct DateOnly : IParsable<DateOnly> // correct implementation of IParsable<TSelf> interface
    { ... }
    public readonly struct MyDate : IParsable<DateOnly> // Warns: "The 'IParsable<TSelf>' requires the 'TSelf' type parameter to be filled with the derived type 'MyDate' " the type parameter TSelf 
    { ... }
  • Prevent behavioral change in built-in operators for IntPtr and UIntPtr - Some built in operators added in .NET 7 for System.IntPtr and System.UIntPtr behave differently than the user defined operators in .NET 6 and below. Some operators that used to throw in unchecked context while overflowing now no longer throw unless wrapped within checked context, and some operators that not used to throw in checked context now would throw when overflow unless wrapped within unchecked context. The analyzer detects the code that could cause those behavioral changes and informs it.
    Examples:
    checked
    {
        intPtr2 = intPtr1 + 2; // Warns: "Starting with .NET 7 the operator '+' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."
    
        intPtr2 = intPtr1 - 2; // Warns: "Starting with .NET 7 the operator '-' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."
    
        void* ptr = (void*)intPtr1; // Warns: "Starting with .NET 7 the explicit conversion '(void*)IntPtr' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."
    
        intPtr2 = (IntPtr)ptr; // Warns: "Starting with .NET 7 the explicit conversion '(IntPtr)void*' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."
    }
    
    intPtr1 = (IntPtr)longValue; // Warns: "Starting with .NET 7 the explicit conversion '(IntPtr)Int64' will not throw when overflowing in an unchecked context. Wrap the expression with a 'checked' statement to restore the .NET 6 behavior."
    
    int a = (int)intPtr1; // Warns: "Starting with .NET 7 the explicit conversion '(Int32)IntPtr' will not throw when overflowing in an unchecked context. Wrap the expression with a 'checked' statement to restore the .NET 6 behavior."

@danroth27
Copy link
Member

@JonDouglas I spoke with @lambdageek and the plan is to include the WebAssembly multithreading content in the ASP.NET Core post.

@leecow
Copy link
Member Author

leecow commented Jan 24, 2023

.NET 7 GA is available. Closing these pre-release issues.

@leecow leecow closed this as completed Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants