[BUG] RPC stops accepting requests after a few seconds on .NET Framework 4.8
:information_source: Info
Version: 0.0.1
:speech_balloon: Description
Whenever I attempt to run CSharpRPC on .NET Framework 4.8, the process opens for around 2 seconds or so, then will infinitely yield upon waiting for new requests to respond. Furthermore, each time you run csharpRpc = await CsharpRpc(modulePath).start(); within the Flutter app, it creates a new process under the Flutter program, of which does not close when you stop the app from running (must be closed in Task Manager).
I've tested this in Flutter Debug, although not Release. I've also only tested this within .NET Framework 4.8 / 4.7.2, though I'd be happy to test on other versions if necessary.
:scroll: Pubspec.yaml
name: rpc_testing
description: A new Flutter project.
publish_to: 'none'
version: 1.0.0+1
environment:
sdk: '>=3.0.6 <4.0.0'
dependencies:
flutter:
sdk: flutter
cupertino_icons: ^1.0.2
csharp_rpc: ^0.0.7
dev_dependencies:
flutter_test:
sdk: flutter
flutter_lints: ^2.0.0
flutter:
uses-material-design: true
CSharp Program
Program.cs
using FlutterCsharpRpc;
using System.Threading.Tasks;
internal class Program
{
static async Task Main(string[] args)
{
await CsharpRpcServer.StartAsync(new Server());
}
}
Server.cs
using System;
public class Server
{
public void RunTest()
{
Console.Error.WriteLine($"Received new 'RunTest' request")
}
}
csproj file
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net472</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="FlutterCsharpRpc" Version="0.0.1" />
</ItemGroup>
</Project>
Flutter Program
only the first doInjectLoop() stuff is important here
import 'package:flutter/material.dart';
import 'package:csharp_rpc/csharp_rpc.dart';
late CsharpRpc csharpRpc;
void doInjectLoop() async {
print("starting loop");
var modulePath = r"C:\Users\eric\source\repos\Project1\Project1\bin\Debug\net472\Project1.exe";
csharpRpc = await CsharpRpc(modulePath).start();
while (true) {
print(await csharpRpc.invoke(method: "RunTest"));
await Future.delayed(const Duration(seconds: 1));
}
}
void main() async {
doInjectLoop();
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
// This widget is the root of your application.
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
useMaterial3: true,
),
home: const MyHomePage(title: 'Flutter Demo Home Page'),
);
}
}
class MyHomePage extends StatefulWidget {
const MyHomePage({super.key, required this.title});
final String title;
@override
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
int _counter = 0;
void _incrementCounter() {
setState(() {
_counter++;
});
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
backgroundColor: Theme.of(context).colorScheme.inversePrimary,
title: Text(widget.title),
),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
const Text(
'You have pushed the button this many times:',
),
Text(
'$_counter',
style: Theme.of(context).textTheme.headlineMedium,
),
],
),
),
floatingActionButton: FloatingActionButton(
onPressed: _incrementCounter,
tooltip: 'Increment',
child: const Icon(Icons.add),
), // This trailing comma makes auto-formatting nicer for build methods.
);
}
}
Let me know if I can provide anything else!
Hello @EricApostal
Yes you right, I was able to reproduce it on my computer, the package works only with .NET (Core) and not with .NET Framework unfortunately 😢
Sorry, I haven't been able to test it on .NET Framework.
Added note in the documentation:
Ah okay, thanks for getting back so fast! I'll find a way to use .NET core.
Given the relationship between .NET (Core) and .NET Framework, there's about a million incompatibilities. So I'm pretty sure the only way to truly support .NET Framework is by creating a separate solution/project with that target. However given that it is basically all but deprecated at this point I strongly encourage not adding backwards compatibility.
In fact... as I wrote this I had to fact check, .NET Framework is officially no longer supported as of April 26, 2022. https://devblogs.microsoft.com/dotnet/net-framework-4-5-2-4-6-4-6-1-will-reach-end-of-support-on-april-26-2022/
Probably safe to close this unless you're dead set on adding support for a deprecated framework.