I have a C# Publisher-Subscriber project intended to make use of the MSMQ service in Windows. The code was developed in .Net Framework 4. I want to run it in .Net Core. But I am getting the error
"The type or namespace name "Messaging" donot exist in the namespace System".
Does .Net Core support MSMQ?
Does .Net Core has a corresponding System.Messaging.dll which appears to be missing.?
MSMQ is not platform independent and therfore not supported by .Net Core.
Even though MSMQ is Windows only, the future even on Windows is .NET Core and .NET Framework basically is end-of-life.
Currently the only way to use MSMQ on .NET Core is via the following package:
https://github.com/krazure/Experimental.System.Messaging
Related
My team has written maintains a library that wraps functionality around a full framework .net .dll, specifically the IBM FileNet.Api.dll. We have been transitioning our library to use .net Standard and so far, all is well. After creating a .net core app and attempting to connect to FileNet, we run into a web service runtime problem.
Here is the error that is thrown:
The operation cannot be completed because a supported web service
runtime is not present. Either Microsoft Web Services Extensions (WSE)
3.0 or the Windows Communication Foundation (WCF) is required.
Does anyone know of a NuGet package that provides this runtime for .net Core or a workaround for this issue?
Updade:
I have now had several conversations with the engineer team at IBM and they do not support .NET Core, nor do they plan on supporting it at this time. What I am doing is to create a .NET Framework 4.x API to basically convert to and from FileNet. It's a bit janky but when the customer wants their API in .NET Core I'm having to build something to make it work.
I'm running into the same issue. From what I've discovered System.Web.Services which is used by the FileNet.Api.dll and IBM's CEWSI for creating SOAP connections has been deprecated after .NET Framework 4.x in favor of WCF and is not available in .NET Core, .NET Standard, nor .NET 5.
It also appears that Microsoft is pushing developers to use REST instead of SOAP. I have not found anything from IBM to replace the DLL or CEWSI.
Sorry this isn't more useful, I'm still trying to figure out how to use .NET Core with it as well and short of basically recreating the functionality myself I haven't found a viable solution.
I have a .Net Core (3.1) Client application that needs to get data from a .Net Framework (4.6.2) application/service. The .Net Framework service communication was written using the .Net Remoting. From what I understood, .Net Core doesn't support several features from .Net Framework, which includes the .Net Remoting.
How should I make the .Net Core Client application get data from the .Net Framework application? It's not an option to change the .Net Framework service to .Net Core because of some time and expertise constraints on that service.
I'm thinking of creating another library project that is targeted to .Net Standard 2.0. This library will be referenced by the .Net Core Client application. And the .Net Standard Library will still be using the .Net Remoting interface to communicate with the legacy service. Would this work?
Another dumb question, how will the remoting configuration be done? Since it's a library, I cant place a .config file in it. The .config file should be on the client project. But, the client project doesn't have the .config file (it only has the appsettings.json and launchsettings.json). I simply creating/adding a project.config file would work? or is there a .json equivalent structure?
This isn't going to work. You have your core application running on a core CLR. It cannot load a library that's using functionality the depends on running on a non-core CLR.
You need to change the language that's being talked between the two applications. If you "can't" modify the existing service, then you probably need to write a new application that will act as a proxy. It'll run independently alongside the service and talk remoting to the legacy application, whilst talking e.g. HTTP or something else supported with the .NET core application.
I have a class library using .Net Framework 4.5, in the code I'm using HttpWebRequest of System.Net.
If I use in a console application using .Net Framework 4.5, it's ok.
If I use in a console application using .Net Core 2.2, it's ok but it's using System.net from .Net Core 2.2 and not from .Net Framework 4.5.
There's a bug/correction in .Net Core 2.2 HttpWebRequest and I want to use the .Net Framework 4.5 version but my application is in .Net Core 2.2.
Is this possible?
Nope. It's best to think of the target framework for a class library as simply an interface. It's dictating a certain API footprint, but the actual framework code is not bundled into the class library.
The actual framework dependencies are satisfied by the end application that utilizes the class library. As long as there's an acceptable level of API compatibility, then you can add the reference, but when it comes time to compile, the target framework will be that of the application itself, not the class library.
If you absolutely need the .NET Framework version, then your only choice is to make your console application target .NET Framework as well, instead of .NET Core. You can still use the new project format; you just won't benefit from cross-platform or things like being able to deploy self-contained.
Issue
Hi,
I am currently working on implementing a RESTful API in C# using ASP.net Core 2.0 in Visual Studio 2017 (running only via Kestrel, therefore no IIS).
Everything works pretty well, no issues there. The thing is that I now need to integrate and start this REST Server in another project (The REST server being only one of many functionalities that need to be executed at the same time, using a "bootstrap"). My issue here is that the latter project targets .Net Framework 4.5.2 whereas the REST server targets .Net Core 2.0. Thus, when I add the REST server to the references of my bootstrap application, I encounter a couple of errors saying that some of the Nuget packages target the wrong framework.
Solutions I tried
I searched over Google but most of the issues I found were people trying to do the other way round, i.e. adding a .Net Framework-targeted project in a .Net Core application.
The way I understood this .Net implementation support table, is that a .Net standard 2.0 project can support a .Net Core 2.0 project (I am probably wrong).
I tried a couple of things to make it work (which, spoiler alert, obviously and unfortunately did not work as I wouldn't be asking your help) :
Made the boostrap application target .Net Standard 2.0
Made the boostrap application target .Net Framework 4.6.1
Made the REST server application target .Net Standard 2.0 (which it of course didn't work, but I was kind of desperate..)
I made these target change by modifying the .csproj files.
I don't have the exact error codes because I reverted my changes a while back but they all were about projects not targeting the same framework.
So, in a tl;dr manner, what I am asking is :
Is there a way to add a .net Core 2.0 REST server inside a .Net Framework 4.5.2 (or 4.6.1 and higher/ or .Net Standard 2.0) project to start the server inside the application ?
Apologies for any english mistake as it is not my native language.
Don't hesitate to ask more info on my problem if I wasn't clear enough and thanks for the help !
I wanted to understand the dot net core support a bit more.
My basic understanding was that if I wanted to run a .net app on Linux then it needs to be built .net core and targeted netcoreapp1.0 framework to guarantee this.
1) I assume the above assumption is correct?
2) When I was reading various articles online, such as this one about referencing exiting .net framework project within a .net core application (https://www.hanselman.com/blog/HowToReferenceAnExistingNETFrameworkProjectInAnASPNETCore10WebApp.aspx)
If I did this, presumably the app would only run on Windows and not Linux?
3) In the following article:
https://blogs.msdn.microsoft.com/cesardelatorre/2016/06/28/running-net-core-apps-on-multiple-frameworks-and-what-the-target-framework-monikers-tfms-are-about/
In context to running with .net run 4.5.2 option (
dotnet run -f NET452), it's mentioned:
If this app were running on the .NET Core Platform, let’s say on a Linux box or a Mac, this code won’t be executed, but the app would
still be running on Linux or MacOS.
What's the distinction between running and not executing? If my initial understanding was correct, then by running with .net 4.5.2 option on Linux I wouldn't expect the app not to run at all.
Appreciate a few questions there but really wanted to understand .net core a bit more.
There is a difference between .NET Core and ASP.NET Core and the articles you mentioned are about running ASP.NET Core "apps" on .NET Framework. Let my try to clarify this using a few declarative statements:
.NET Core is the cross-platform runtime.
ASP.NET Core is a set of libraries that until version 1.1.* can run
on both .NET Framework and .NET Core.
This means you can create a .NET Framework application (=> e.g.
net452) and use ASP.NET Corein this application.
The CLI tooling works for both projects targeting netcoreapp* and
net* - but net* currently only works on windows.
This means that for netcoreapp1.*, you cannot reference arbitrary libraries that have been built for .NET Framework. If you change the target framework to say net452, you are no longer building a .net core application, but a .net framework application.
For ASP.NET Core 2.0 this is going to change. Again a few statements:
ASP.NET Core 2.0 is still a set of libraries but they can only be used on .NET Core 2.0 and not on .NET Framework
Do note that this is still under discussion at the time of writing: https://github.com/aspnet/Home/issues/2022
.NET Core 2.0 is able to freely reference libraries that have been built for .NET Framework up to version 4.6.1
However, some libraries may fail at run time if they try to use API methods that aren't available on .NET Core