Is there a way to use enterprise library in .NET Core 1.1.2 web api - asp.net-web-api

I am planning to use Enterprise Library for database access on a Web API project which is going to be built using .Net core app.
But I am unable to install Enterprise library using NuGet as the latest version of Enterprise Library is not compatible with.Net core app framework.
Note, I don't want to use Entity Framework.
Appreciate if the community can help on this.

If you can migrate your application to .Net Core 2.0 which is still in preview mode, but Microsoft promised to release it by Q3 2017, I have forked out the Enterprise Library project and ported that to .Net Core 2.0 which you can find it under this repository:
https://github.com/Chavoshi/EnterpriseLibrary.NetCore
And also this is the Nuget package for Data Application Block:
https://www.nuget.org/packages/EnterpriseLibrary.Data.NetCore
Still there are some missing parts such as OdbcFactory and OleDbFactory which they are not available in .Net ported APIs (Or Nuget package is not published yet), but I am keep working on them to maybe port them by myself or update it since the API will be available. I appreciate anyone who can contribute on this project as well. :)

Related

What Non-4.* .NET App Versions play well with Standard?

I am building an MVC Web API (Service) with Views returned in specific cases. As an architectural decision, I've been directed to NOT build the service project in .NET Framework 4.*. Rather, I am to attempt .NET 5.0 first, and then Core 3.1 if 5.0 doesn't work.
This service project in my solution will depend on a few class library projects, call them DataLibrary, ComplexLibrary, and DocLibrary. DataLibrary will depend on a Nuget package of Oracle, be it ODP or Oracle Managed Data, in order to query an Oracle database via an Oracle Package on that database. DocLibrary will depend on a Nuget package of Aspose Word & Aspose PDF. ComplexLibrary will depend on Oracle AND Aspose.
Here's my dilemma:
Aspose Word's latest stable release (21.6) will report that it is compatible with 5.0 and Standard 2.0, but not .NET Core.
Oracle Managed Data reports that it is compatible with Standard 2.1 or Standard 2.0, but not 5.0 or .NET Core.
My own libraries have reported that they are not compatible with my API .csproj if...
3a. The API is 5.0 and the libraries are .NET Core or .NET Standard
3b. The API is Core 3.1 and the libraries are .NET Standard.
Since my compile script naturally requires a run of Nuget to retrieve all the necessary dependencies, I cannot get a clean compile because I seemingly have no combination of versions for my WebAPI and libraries that satisfy each others' compatibility needs. Since Standard libraries are the only common .NET version that satisfy the needs of both Aspose & Oracle, What available version for my WebAPI (i.e. I don't believe that Standard is an option for anything other than a class library) is compatible with .NET Standard libraries?
Thanks.
Please see the following article https://learn.microsoft.com/en-us/dotnet/standard/net-standard.
.NET Standard is not a framework it is kind f specification and .NET Core, .NET 5, Mono framework etc are .NET Standard implementations.
So for library projects I would select .NET Standard and for the service .NET Core or .NET 5 (which is actually the next version of .NET Core)
Well, don't I feel silly.
Turns out, the issue wasn't incompatibilities within Aspose, Office, .NET Core, 5.0, and Standard, but a failure of a prior version of NuGet to handle the different versions.
While my VS 2019 install was able to compile the whole solution effectively, my local install of NuGet was not. This was due to VS2019 likely using the most up-to-date version as of this post (5.9.#), while my locally installed version was 4.9.#. Thus, VS was able to sail through while my compile script kept failing at the NuGet stage (which I have included prior to the actual compile.) Once I ran a NuGet update, everything was good to go.
Long story short: KEEP YOUR NUGET VERSION UP-TO-DATE!!!

Performance Issue after .net core 2.1 migration

Existing .Net framework 4.6.2 based web api project & class libraries have been migrated to .net core 2.1 webapi project & its class library have been migrated to .net standard 2.0 with very minimal core, mostly as part of migration either existing nuget package has been upgraded and existing package was swapped with .core compatible SDK version with very minimal/negligible code changes.
Right after the migration application's entire functionalities facing performance issue.
Once.Net framework based out code has been migrated to .net core, is the performance issue expected one?
Any effective open source tool to profile & measure performance?
Any mitigation to solve these performance issue? please suggest

Creating Azure Function Project in .NET Core Targets .NET Framework

I upgraded my Visual Studio 2017 to the latest version i.e. 15.3. I then upgraded the VS Extension for Azure Functions and WebJobs.
When I create a new Azure Function project targeting .NET Core 2.0, it still targets .NET Framework. See below...
This is the project file:
P.S. To be fair, the dialog says .NET Framework 2.0 NOT .NET Core 2.0. So I guess MS means literally targeting .NET Framework 2.0!!!
Update 12/21/17 See newer post here: Develop Azure Functions on any platform
Previous answer
The behavior can be a bit confusing; I've now clarified the blog post: Azure Functions Tools released for Visual Studio 2017 Update 3.
The project type is .NET Standard, but we don't currently support the .NET Standard 2.0 facades in the Azure Functions runtime. Now that .NET Standard 2.0 is RTM, we will make this update in a future release. Once this happens, you won't have to make any project changes other than changing the target framework.
Currently, Azure Functions runs only on full framework, so there is no benefit to targeting netstandard2.0. However, we are porting the runtime to .NET Core, at which point there is a difference. Once that work is complete, the New Project dialog will target netstandard2.0 by default.

Microsoft ASP.NET Web API 2 on .net 4.0

Is it possible to use ASP.NET Web API 2 with .net 4.0? I tried to upgrade from an older version but I get:
Could not install package 'Microsoft.AspNet.WebApi.Client 5.0.0'. You
are trying to install this package into a project that targets
'.NETFramework,Version=v4.0'
To answer my own question:
No, it is NOT possible to use Web API 2 with .net 4.0:
This is taken from a slide by Damian Edwards. You can find additinal info here.
FWIW, I had a .NET 4.0 requirement on the client (die WinXP!), but I could do .NET 4.5 on the server. So, I have WebApi2 running server side, but the WebApi1 client package running on the client, handling serialization, etc.
Using the Package Manager Console in Visual Studio and choosing my client project in the default project dropdown, I was able to:
Install-Package Microsoft.AspNet.WebApi.Client -Version 4.0.30506.0
Everything thereafter worked well.

How to install SignalR.Client.NET35 to a project

I am using SignalR 0.5.3, installed via NuGet, for my .NET 4.5 Web Application - now, since I need to push data from SQL SERVER 2008R2 (supporting only the .NET Framework up to 3.5), I need to create a library using the SignalR .NET 3.5 Client.
I have seen in the project website that there is probably a SignalR.Client.NET35 version but (being not very familiar neither with github nor with NuGet) I have no clue how to install that client for the library project I have to work on.
I have tried installing with the std command install-package SignalR.Client but the message i get is:
Install-Package : Could not install package 'SignalR.Client 0.5.3'.
You are trying to install this package into a project that targets
'.NETFramework,Version=v3.5', but the package does not contain any assembly
references that are compatible with that framework.
For more information, contact the package author.
so it looks like the right .NET version is not picked correctly/out of the box.
Before bothering the author, i thought to give a try round here.
Any suggestions?
We haven't packaged the 3.5 client into the package as yet. You'll need to build from source.
I backported the v1.x and v2.x SignalR clients to NET 3.5. Available as NuGet packages here: http://www.nuget.org/packages/Nivot.SignalR.Client.Net35/

Resources