I will explain briefly my situation before asking for recommendations:
Context
Among other topics* I have been asked to develop a REST api that will be on the cloud (Azure)
The current (soon legacy) application works with windows service.
Behind this web API/windows service that receive the data and deserialize it (before serializing again when sending the response) there is Pricing Library which is used to compute data provided by custom-xml format.
The problem
I am quite concerned with compatibility issues as I keep encountering errors due to uncompatibilities from external libs with .NetCore 2.0
I had an issue with log4net as the Pricing Lib is using 1.2.13 version while 2.0.8 is already available. I solved this but I now encounter RealProxy in dotnet core? issue
I feel I will keep encountering new issues and it will be really time-consuming to fix them each time. But perhaps I am wrong since I only want to revamp the web API with .netcore 2 (not the pricing lib) ?
My question
Is it really profitable, performance wise, or functionally-wise, to switch now the web API to .NetCore 2.0 knowing that we call a Pricing Lib in 4.6.2 .Net Framework ? Is it worth to bother that much just to be using the trending framework while the former one is rather mature ?
Many thanks for your answers~ !
PS: I have already googled and read the relevant documentation, I am asking about experience from other users
https://learn.microsoft.com/en-us/dotnet/standard/choosing-core-framework-server
*code optimization, configuring automatic build and deployment, markdown doc etc.
Related
Post the question in a different way, because the previous one was closed because it was opinion-based.
In the past I have developed several .NET applications that consumes WCF services hosted on IIS with MSSQL database.
Now the company is asking me a technology switch (for licensing reasons - current MS server is getting old and needs to be replaced) and I have do do the same but with a Linux server, so I need that the same .NET applications to connect to this server to retrieve the data in the same way that they do now with MSSQL (service reference).
So I need to rewrite the WCF service to a new technology that could be hosted in Linux. I know for sure that I have to learn a new technology to do that but I would like to be sure I choose the right one.
These are my actual skills :
Writing C# code
Writing VB.NET code
SQL and MySQL
Some Python basics
This is what I have done so far :
Build a Linux test machine with Debian distro and installed Mono and .Net Core
Installed MariaDb database and built table schema
Do you think that ServiceStack could be a good choice to fit my needs?
If so, what are the suggested steps to getting startet with it?
Thanks!
Do you think that ServiceStack could be a good choice to fit my needs?
So ServiceStack runs on .NET Core and Mono but you shouldn't consider Mono for Web Apps as .NET Core is far more performant, resilient & better supported.
ServiceStack includes a code-first ORM in OrmLite that you can use to quickly develop DB Apps which supports MySql/MariaDB.
ServiceStack also supports AutoQuery where it can implement full Queryable Services for your OrmLite data models with just a simple Typed Request DTO declaration.
And in the pre-release version (now available from v5.8.1 on MyGet) it also supports AutoCrud and AutoGen AutoCrud Services which makes it possible to rapidly develop full CRUD APIs with declarative Request DTOs.
All these features are supported and perform even better on .NET Core thanks to its leaner & faster runtime & thanks to its cross-platform support you can take advantage of the simpler & superior tools and Services for hosting & deployment in the Linux ecosystem.
If so, what are the suggested steps to getting startet with it?
I'd recommend following the Getting Started section and reading the Background Concept docs if you're new to ServiceStack to get a background understanding on its design & goals.
I have been trying to anticipate the issues I may face when trying to migrate an existing API developed in .NET framework 4.5 and deployed in an IIS to a serverless architecture based on AWS Lambda.
Currently, the API is divided in: Controller (entry point), service (buz logic) and repository (basically LINQ), and of course some DTO and DAO's, nothing fancy. In addition, I have got some dependencies to external libraries but I don't know if that really matters.
Here is the thing: As I could see when configuring my Lambda, it only accepts .Net Core applications. Ouch! Then, is it necessary to migrate to .Net Core? If it is, can anyone tell me how much development that requires considering my set up?
Is it necessary to migrate to .Net Core?
Yes, as Lambda runs on Linux.
If it is, can anyone tell me how much development that requires considering my set up?
You will need to pay specific attention to the dependencies to external libraries, as they need to support .NET core and might add a substantial load time to your lambda function.
If you have an existing .NET API developed in 4.5, I would strongly advise against trying to migrate the whole API. Lambda's pay-for-what-you-use model is very attractive, but largely incompatible with ASP.NET MVC/WebApi's server model.
(First i just want to say i'm sorry if its not worded the best but i have been researching for hours and i thought maybe someone on here could clear this up for me)
Im new to creating web apis and i have been googling just doing some research and i have built a few MVC applications just to get exposed but i never really thought of making an API for it until today. One of the reasons its listed to be useful is it allows your application to be used across tablets and smart phones etc. What im not understanding is how you would do this as in would you just add something to the API so it makes it compatible for all browsers or if i need to re build it using Web API instead of MVC.
Thanks,
I think your looking at a Web API from the wrong perspective. It's not really about compatibility necessarily, but rather about the ability to reuse the code/back-end functionality.
So rather than having your dependencies all wrapped up in one MVC project, the references are external. This allows for essentially the same functionality across multiple projects as long as the request are being handled in the same manner.
I am facing the following scenario and would appreciate some advice on how best to iterate forward:
My team is responsible for a Web Service written on ServiceStack v3. This service is responsible for aggregating data from several other v3 web services for use in a SPA.
We are running into a situation where we are limited by the implementation of a downstream service - this particular service abstracts away data access and queries that return large result sets occasionally timeout.
We would like to rewrite this service to add pagination. The best solution (for us) would be to leverage AutoQuery from ServiceStack v4. However this would require upstream code being able to reference ServiceStack packages in 2 versions (is this possible?). We could also add pagination to the existing service, but it uses an internal data framework that is not that easy to change and we have a high chance of breaking.
Any ideas?
Yes, you can load in 2 versions of a dll inside your application. No, not while developing (only runtime) but I'm pretty sure this will lead to big problems in code execution (it wont be able to find the right class-version run-time).
Your question is also answered here: Using multiple versions of the same DLL
A better solution would be is to split your application into a v4 and v3 part using app domains also talked about in this question.
Original problem?
your original problem is you have old v3 services where you want to add pagination for performance issues?
Solution could be to add it in the v3 parts but this might break the services and they have to be tested?
You could migrate 3 to 4 (i'm not sure if this would fix your problem). I've found this is still very do-able.
Create your own wrapper services using redis caching (adv: no changing in the original code)
Build in a caching mechanic client-side/intermediary so you don't need to wait on the long api call.
migrate to autoquery. (I have no experience here)
Roadmap
I think you'd do good researching some of these options. I think your case there is not one perfect solution, there is only pros and cons.
To you to decide which risks to take.
I'm working on an application that requires me to host a WCF REST Web App using Windows Service. Now since it is going to be a bit more complicated than just a small API, I would like leverage MVC capabilities as a lot of things would be lot easier if done using the 'Controller' way (if I can say so). I'm don't have deep knowledge of MVC and Windows Service.
So far, I've found only two links here & here, that are somewhat related to what I want, but still not there. Could anyone please point me to a working example or create a small demo? TIA.
Based on your comments, it is clear that you are wanting to run REST-based web-services, self-hosted, on both Linux and Windows.
The recommended way to do this is to use the new ASP.NET Core platform, running on .NET Core.
Microsoft provide a good tutorial here:
https://docs.asp.net/en/latest/tutorials/first-web-api.html
Another link just received from a quick google search Here but yes need some more clarity on how you plan to run it or what its for.
We used Nugent package manager years ago for self-hosting a web API