Mhm, just a sign of the times.
30 years ago, if a device had a terminal interface accessed via RS-232 port, you could technically call that an API, because it is an Application Programmer Interface. Though those ports were usually marked Computer Interface/Port
Still technically correct but I do understand today an API is generally understood to be some kind of platform leveraging http or another communication model.
You’re correct though theirs appears to be a series of dlls they want you to use to properly communicate with their actual API.
API simply means application programming interface. Libraries have APIs. Every module/class you implement has an API. Not all APIs are restful and over http. In fact most APIs you use are not over http.
I’m well aware. Im commenting on marketing norms. In dotnet API is thrown around like crazy and it confuses newer programmers. That’s just one example.
It's been a while since I've had to do this, but couldn't he wrap the API in his own with .NET standard 2.0? Then just reference that from his .NET 8 front end?
Yes, this is a way to do this and we do it ourselves to "liberate" our plugins from the main app that has an unfortunate dependency on .NET Framework. .NET Standard 2.0 is like the intersection of API coverage that both .NET Framework 4 and .NET Core supports. Depending on what you need to do (it won't support as much as either of the two - but what they have in common), it might work.
Otherwise I'd be pretty happy to simply sit in WPF too. OP can use e.g. WPFUI if a slicker Windows 11 UI is requested. It supports .NET Framework.
You absolutely **can** reference a .Net v4.7 (any full .Net Framework version) assembly from a modern .Net (Core v2.2, v3.x, v5, v6, v7, v8) application.
It just works, thanks to the Compatibility Shim.
It will, however, throw an exception at runtime if the full .Net Framework code calls a class or method that does not exist in the modern .Net runtime environment the application is running under - but a huge amount of pre-existing code will work 100%.
The problem with this approach is that a single issue can torpedo the entire interface. It’s an all or nothing type of thing.
That’s what happened to me and my attempt to do this. One small 3rd party DLL that the . Net framework lib was dependent on wouldn’t run under .net core and I had to abandon this approach.
One option is to write a modern .NET 8.0 Blazor Web App and then in the same solution write a .NET Framework 4.8 project that heavily leans on WebView2 Controls.
[https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/winforms](https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/winforms)
Essentially you write the UI in Blazor, the Winform is pretty much running a stripped down Edge Instance to render the Blazor Site. You also get some interop between the blazor site and the winform project via javascript.
I've been toying with this idea for a few older libraries, especially as I can design the app in Blazor for a new modern look and new modern features and then only a few Blazor pages/components would be for the older library. So if you navigate to a page/component that is for the old stuff, it just would display some error "Please access from MyApp.exe", and then "MyApp.Exe" would simply hide that message when it loads.
I haven't committed to it yet, but just threw a test solution together to try it. Looks pretty neat: [https://imgur.com/a/FfL4whO](https://imgur.com/a/FfL4whO)
Only thing I ran into was I had to manually add the WebView2 control via code. Adding it via toolbox gave me an Object Reference Error
public partial class Form1 : Form
{
private WebView2 webView2;
public Form1()
{
InitializeComponent();
//Add/Initialize WebView2 - Dock Full Screen in Form
webView2 = new WebView2();
webView2.Dock = DockStyle.Fill;
Controls.Add(webView2);
//Set the home page of the webView2 Control
webView2.Source = new Uri("https://localhost:7008");
Shown += Form1_Shown;
//One Weird behavior I found in testing is the Webview2 control
// does not dispose automatically when the form is closed.
//
//Not a bit deal if it's the main form as Application Exit takes care of it,
// but just a habit to get into on subforms
// so you ensure it gets disposed
FormClosing += Form1_FormClosing;
}
//Dispose the Webview2 control when the form is closing
private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
webView2.Dispose();
}
//Show Winform Messagebox to prove we're still in WinForms
private async void Form1_Shown(object sender, EventArgs e)
{
await Task.Delay(3000);
MessageBox.Show("I'm a Win Form App!");
}
}
BlazorWebView is a similar control for .NET MAUI which is a completely different framework.
Never used MAUI, it gets pretty mid to bad reviews around here. As far as I know you can't use .NET Framework libraries with a project that is using MAUI.
So pretty much same control, just WebView2 is for WinForm/WPF and BlazorWebView is for MAUI
Couple of ways you can do that
1. Pretty trivial to add some [Asp .net controllers to make a web API](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.controllerbase?view=aspnetcore-8.0) to the Blazor side of things and use a .net framework http client to call it.
2. Use a SignalR hub on the Blazor side and a SignalR client on the .NET Framework side
3. Use the javascript method described in the first article I linked.
CANoe doesn't look like a web API, looks like it's a bunch of libraries
[https://cdn.vector.com/cms/content/know-how/\_application-notes/AN-IND-1-011\_Using\_CANoe\_NET\_API.pdf](https://cdn.vector.com/cms/content/know-how/_application-notes/AN-IND-1-011_Using_CANoe_NET_API.pdf)
API should be addressable from any technology. That's the point of API.
I'm willing to bet the company markets it as "API" but really it's more of a SDK, being a collection of .dlls and other libraries.
Indeed. People nowdays assumes that API = HTTP rest-like web service and it's really annoying.
Mhm, just a sign of the times. 30 years ago, if a device had a terminal interface accessed via RS-232 port, you could technically call that an API, because it is an Application Programmer Interface. Though those ports were usually marked Computer Interface/Port
Still technically correct but I do understand today an API is generally understood to be some kind of platform leveraging http or another communication model. You’re correct though theirs appears to be a series of dlls they want you to use to properly communicate with their actual API.
API simply means application programming interface. Libraries have APIs. Every module/class you implement has an API. Not all APIs are restful and over http. In fact most APIs you use are not over http.
I’m well aware. Im commenting on marketing norms. In dotnet API is thrown around like crazy and it confuses newer programmers. That’s just one example.
Not exactly. APIs are not universally accessible. They are simply defined interfaces. More specific terms should be used.
No, review the .NET compatibility chart. Natively you cannot reference them in each others project
It's been a while since I've had to do this, but couldn't he wrap the API in his own with .NET standard 2.0? Then just reference that from his .NET 8 front end?
Yes, this is a way to do this and we do it ourselves to "liberate" our plugins from the main app that has an unfortunate dependency on .NET Framework. .NET Standard 2.0 is like the intersection of API coverage that both .NET Framework 4 and .NET Core supports. Depending on what you need to do (it won't support as much as either of the two - but what they have in common), it might work. Otherwise I'd be pretty happy to simply sit in WPF too. OP can use e.g. WPFUI if a slicker Windows 11 UI is requested. It supports .NET Framework.
Great answer. This might be very useful, how can I get more information about it?
Yes, will have to do something that meets in the middle like this. Just not possible naturally as is
You absolutely **can** reference a .Net v4.7 (any full .Net Framework version) assembly from a modern .Net (Core v2.2, v3.x, v5, v6, v7, v8) application. It just works, thanks to the Compatibility Shim. It will, however, throw an exception at runtime if the full .Net Framework code calls a class or method that does not exist in the modern .Net runtime environment the application is running under - but a huge amount of pre-existing code will work 100%.
The problem with this approach is that a single issue can torpedo the entire interface. It’s an all or nothing type of thing. That’s what happened to me and my attempt to do this. One small 3rd party DLL that the . Net framework lib was dependent on wouldn’t run under .net core and I had to abandon this approach.
Never saw it working, especially.NET Framework ref. to .NET 8; any official documentation about this support / shim?
If you are targeting windows only and are blocked on net framework because of CANoe, you can use WPF or Winforms.
If they need responsive screens then I'd probably avoid winforms. Technically you can do it but it sucks.
Thank you.
One option is to write a modern .NET 8.0 Blazor Web App and then in the same solution write a .NET Framework 4.8 project that heavily leans on WebView2 Controls. [https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/winforms](https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/winforms) Essentially you write the UI in Blazor, the Winform is pretty much running a stripped down Edge Instance to render the Blazor Site. You also get some interop between the blazor site and the winform project via javascript. I've been toying with this idea for a few older libraries, especially as I can design the app in Blazor for a new modern look and new modern features and then only a few Blazor pages/components would be for the older library. So if you navigate to a page/component that is for the old stuff, it just would display some error "Please access from MyApp.exe", and then "MyApp.Exe" would simply hide that message when it loads. I haven't committed to it yet, but just threw a test solution together to try it. Looks pretty neat: [https://imgur.com/a/FfL4whO](https://imgur.com/a/FfL4whO) Only thing I ran into was I had to manually add the WebView2 control via code. Adding it via toolbox gave me an Object Reference Error public partial class Form1 : Form { private WebView2 webView2; public Form1() { InitializeComponent(); //Add/Initialize WebView2 - Dock Full Screen in Form webView2 = new WebView2(); webView2.Dock = DockStyle.Fill; Controls.Add(webView2); //Set the home page of the webView2 Control webView2.Source = new Uri("https://localhost:7008"); Shown += Form1_Shown; //One Weird behavior I found in testing is the Webview2 control // does not dispose automatically when the form is closed. // //Not a bit deal if it's the main form as Application Exit takes care of it, // but just a habit to get into on subforms // so you ensure it gets disposed FormClosing += Form1_FormClosing; } //Dispose the Webview2 control when the form is closing private void Form1_FormClosing(object sender, FormClosingEventArgs e) { webView2.Dispose(); } //Show Winform Messagebox to prove we're still in WinForms private async void Form1_Shown(object sender, EventArgs e) { await Task.Delay(3000); MessageBox.Show("I'm a Win Form App!"); } }
should we use BlazorWebView? What are the differences between blazorwebview and web view2？
BlazorWebView is a similar control for .NET MAUI which is a completely different framework. Never used MAUI, it gets pretty mid to bad reviews around here. As far as I know you can't use .NET Framework libraries with a project that is using MAUI. So pretty much same control, just WebView2 is for WinForm/WPF and BlazorWebView is for MAUI
How do you handle frontend and backend communication on webview2？
Couple of ways you can do that 1. Pretty trivial to add some [Asp .net controllers to make a web API](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.controllerbase?view=aspnetcore-8.0) to the Blazor side of things and use a .net framework http client to call it. 2. Use a SignalR hub on the Blazor side and a SignalR client on the .NET Framework side 3. Use the javascript method described in the first article I linked.
[удалено]
CANoe doesn't look like a web API, looks like it's a bunch of libraries [https://cdn.vector.com/cms/content/know-how/\_application-notes/AN-IND-1-011\_Using\_CANoe\_NET\_API.pdf](https://cdn.vector.com/cms/content/know-how/_application-notes/AN-IND-1-011_Using_CANoe_NET_API.pdf)