https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.handleref(v=vs.110).aspx
I don't see HandleRef in .NET Core.
So, what is the safe/recommended way for managing references to IntPtr in .NET Core?
Related
There is OracleCoherence.dll v12.2.1.3 for .Net Framework.
What is the equivalent OracleCoherence package for target framework .Net Core 3.1
This has been taken into consideration by the team.
https://github.com/oracle/coherence-dotnet-extend-client/issues/1
I created a new .net core 3.1 project and built it using VS2019 16.4.4
Now I want to change it to .Net Standard.
I know to go to the project properties and select the Target framework combo.
However no Standard framework options appear.
If I select Install other frameworks then I am taken to The download .Net SDKs for Visual Studio page
However the SDK I want is already installed on my machine.
Why am I not seeing what I want in the combo box.?
.NET Standard, like .NET Core and .NET Framework, is separate framework, so you can't switch that easily. You would need to create separate project targeting .NET Standard. Once you do it, you will see other options in 'Target framework'.
Worth to mention, you can't reference .NET Core and .NET Framework projects from your .NET Standard library, since .NET Standard is just an abstraction which is built differently depending on the executing environment (.NET Core or Framework)
We currently have a web api targeting .NET 4 framework which is hosted within IIS using an application pool which is using .NET 4 CLR.
We are investigating migrating the web api from .NET 4 to .NET Core 2.1 (for performance improvements). The web api has other DLL references which have been built using .NET 4 framework. I have a simple proof of concept up and running using .NET Core 2.1 and the references which had been built using .NET 4 framework appear to have imported fine as I can reference them and the project builds.
If I have the new .NET Core 2.1 web api referencing the 3rd party DLLs using .NET framework 4 which is then going to be hosted in IIS using the CLR 4... how would we see any performance increase? If everything is being run using the CLR 4, is that not the bottleneck for performance? Or is it the binaries that the CLR reads being more performant where you will see better performance?
Any guidance would be greatly appreciated as I'm very confused at the moment!
Thanks
It depends on how you're handling things. .NET Core 2.0+ fully supports .NET Standard 2.0, which has an API footprint large enough to cover most .NET Framework functionality. As a result, the compiler will let you add a .NET Framework library reference to a project that's actually targeting .NET Core 2.0+. There's no guarantee that the library will actually work (and you get a warning to that effect), but unless it's using Windows-specific APIs, there's a very good chance it will function fine.
Assuming this is the case with your .NET Framework libraries and you're actually targeting something like .NET Core 2.1, then you are not in fact using .NET Framework, and you don't even need .NET Framework installed on the server you're deploying to. All the requisite framework dependencies will come from the .NET Core runtime, or can even be packaged along with your app if you opt for a self-contained deployment. In that case, once compiled, it's virtually inconsequential that the libraries you referenced actually targeted .NET Framework.
If however the libraries do not work without full .NET Framework, you can still build a .NET Core app, but you'll be forced to continue to target .NET Framework, rather than .NET Core. In that case, you will of course be reliant on the .NET Framework CLR, with the performance drain that entails. That said, an ASP.NET Core app, for example, is still generally more performant than something like an ASP.NET MVC app, so you will get some gains - just not as much as if you were actually targeting .NET Core.
Regardless of what you ultimately end up targeting, your app is actually served via Kestrel. IIS acts merely as a reverse proxy.
Does ASP.Net Core 1.0 support .Net WebForm projects? Or it is an MVC only environment? Also can I create classic web services(asmx) there?
Short answer: No, ASP.NET Core does not contain Web Forms or Web Services.
Long answer:
Depends on your meaning of "support". If you aim to run ASP.NET Core project on top of CoreCLR and CoreFX, then the answer is no: ASP.NET Core will contain support only for MVC ja Web API -projects (which are the same thing in ASP.NET Core).
If you can run on full .NET Framework, then ASP.NET Web Forms can co-exist with ASP.NET Core. The Web Forms will be the same Web Forms they are today on System.Web. In this scenario you would host your web forms in a different project (normal ASP.NET 4.x application) on IIS and ASP.NET Core would live in it's own application on Kestrel.
A need to use .NET technologies not available for .NET Core
Some .NET Framework technologies are not available in .NET Core. Some of them will be available in later .NET Core releases, but others don’t apply to the new application patterns targeted by .NET Core and may never be available. The following list shows the most common technologies not found in .NET Core 1.0:
ASP.NET Web Forms applications: ASP.NET Web Forms is only available on the .NET Framework, so you cannot use ASP.NET Core / .NET Core for this scenario. Currently there are no plans to bring ASP.NET Web Forms to .NET Core.
ASP.NET Web Pages applications: ASP.NET Web Pages are not included in ASP.NET Core 1.0, although it is planned to be included in a future release as explained in the .NET Core roadmap.
ASP.NET SignalR server/client implementation. At .NET Core 1.0 release timeframe (June 2016), ASP.NET SignalR is not available for ASP.NET Core (neither client or server), although it is planned to be included in a future release as explained in the .NET Core roadmap. Preview state is available at the Server-side and Client Library GitHub repositories.
WCF services implementation. Even when there’s a WCF-Client library to consume WCF services from .NET Core, as of June 2016, WCF server implementation is only available on the .NET Framework. This scenario is not part of the current plan for .NET Core but it’s being considered for the future.
Workflow related services: Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service) and WCF Data Services (formerly known as “ADO.NET Data Services”) are only available on the .NET Framework and there are no plans to bring them to .NET Core.
Language support: Visual Basic and F# don’t currently have tooling support .NET Core, but both will be supported in Visual Studio 2017 and later versions of Visual Studio.
source Choosing between .net Core and .net Framework
Can you use Ninject 2.0 with VS2010 RC1?
I had similar issue... try targetting the full .NET 4 Framework, not the Client Profile.
From my understanding System.Web is in .NET 4, but not the .NET 4 Client Profile. So for your assemblies, in which you are taking advantage of full Ninject compiled against 3.5 sp1, you will need to ensure they are not targeting the .NET 4 Client Profile but the full .NET 4 profile in order for the dependency on System.Web to be satisfied.
Even if it is compiled for .NET 3.5, the assembly should be able to run in .NET 4. Here's a nice picture.