everybody!
I have a piece of code which calls win service remotely with Activator.GetObject(type, url). But the project is targeting .net framework and we're going to migrate to .net standard. The later, though, does not provide such behavior.
Is there a way to do the same action in .net standard?
Related
I need to reference a proprietary-client library that only works with .NET 4.8, there is no other option, this is a very narrow vendor library and we have to use it with .NET 48.
The new app that is being developed is a service application and will need to be maintained in the long term. And it's ok for this app to be installed on windows only. But we would like the application to benefit from .NET 6, while being able to use the .NET 4.8 client library.
So my question is : what would/could be a good solution that:
respects that I need some code in 4.8 to work with that library.
leverages .NET 6 and future enhancements
Thanks for your help!
Yes you can reference .NET 4.8 assembly from .NET 6. However, there are no guarantees it will work as expected. It will work only if it does not use any APIs which are not present in .NET 6 (or rather .NET Standard version supported by .NET 4.8), and if APIs it uses did not have breaking (for that application logic) changes.
You can easily test it by creating .NET 4.8 library with something like this:
public class Test
{
public static void OldNet()
{
Console.WriteLine("Hello from old .NET");
}
}
Then reference it from .NET 6 and call:
OldNet4.Test.OldNet();
Run and it will print "Hello from old .NET" no problem.
However if you for example use Thread.Abort in that old .NET 4.8 library - when running on .NET 6 it will not abort the target thread but instead will throw PlatformNotSupportedException, which is an example of breaking change. If it calls missing api, then it will throw TypeNotFound or similar exceptions.
So the end result depends on the library being referenced.
Yes, it is possible to have a client written in .NET Framework 4.8 and a server in .NET Core 6. It's possible to have a client and a server written in different programming languages as well, so there's no reason that your use case wouldn't be possible. However, it's not possible to reference a .NET Core assembly from a .NET Framework assembly.
I created a new project in VS 2019 in .NET Framework 4.6 and now I want to upgrade it to .NET Core 3.1.
I do not want to do manually because their is ton of code.
How can I do this?
Microsoft published a guide for porting .NET Framework applications to .NET Core:
https://learn.microsoft.com/en-us/dotnet/core/porting/
In a nutshell, it boils down to the following:
Manually convert your dependency and project files.
Ensure that all your dependencies are compatible with .NET Core.
Use the .NET Portability Analyzer to find out if you are using features which are not supported in .NET Core.
Use the .NET API analyzer to find out if you are using features which are not supported on some platforms.
Target .NET Core, fix compile errors and test.
The guide contains detailed descriptions for specific steps (e.g., how to port your WinForms/WPF UI code), which are too long to paraphrase in an SO answer, so be sure to read it carefully.
I do not want to do manually because their is ton of code.
Then you'll have to pay a developer to do that for you. Sorry, but at the time of writing, there is no fully automated .NET Framework -> .NET Core converter available.
I am writing a simple .NET 4.6.1 console application (not .NET core), as below
References are
The problem is, once compiled, it generates a hefty lot of dlls that are supposed to be build-in dlls. What is the problem?
You left a big clue in the screenshot.
They're recommending that libraries target .NET standard.
There's a good discussion at:
https://github.com/dotnet/standard/issues/146
Libraries should generally target .NET Standard as this ensures that
they can be consumed by any app. There will be circumstances where you
need to access .NET Core specific APIs, either because the API is new
and not implemented anywhere else, or the concept is .NET Core only.
That's why I believe we should make it easy to retarget between .NET
Standard and .NET Core so that developers never have to fear being
"locked in". Start with NET Standard and retarget if necessary &
revert back once a new version of the standard is available that has
all the APIs you need.
So gRPC now works with .NET Standard.
If you don't want to opt-in, you could build the particular library targeting the .NET Framework.
We've a server side "classic" WCF .NET application running on Windows. We added last year Linux support using Mono and a Web-Api replacement of WCF.
Checking the compatibility with the Api-Port tool, we found that the we would need much few changes targeting directly .NET Core instead of .NET Standard.
So for server side application like ours, that will be running only on Windows and Linux, is it correct to say that does not make any sense to target .NET Standard?
For server-side applications targeting .NET Core is enough.
There is a detailed answer here: What is the difference between .NET Core and .NET Standard Class Library project types?
If I make .NET 4.0 API calls and the customer only has .NET 2.0 installed, will my EXE work? I assume no -- absolutely not. But I want to reconfirm and point this out to my client yes/no.
Background... I'm from the Linux/PHP world. My client uses a Windows C# app on the frontend, and Linux/PHP on the backend. He's asked me to investigate this issue.
The .NET 2.0 runtime will error out on you when trying to run anything written and compiled with .NET 4.0, the reverse is not true.
Application code targeted against the .NET 4.0 framework will not run in an environment that only has the .NET 2.0 framework installed.
See "Version Compatibility" section here:
http://msdn.microsoft.com/en-us/library/8477k21c.aspx
What you can do is have your .NET 2 code access the .NET 4 libraries via a web service. If you were to expose the .NET 4 API via a web service, it would be agnostic of the .NET version and the technology between them all together.