I am trying to determine whether or not to start using ServiceStack V4 for development purposes. I currently use ServiceStack V3 which I am pretty familiar with. My question is though, what are the big differences, aside from licensing costs and ongoing support, between ServiceStack V3 and V4? I know V4 added support for Async funcitons, and Ormlite has improved joining abilities, AutoQuery. Is there anything else that would really be worth making the investment and switching from V3 to V4? It would really be helpful to have a list of improvements and or side by side comparison between the 2 versions of the framework.
The features that are added in each release are now being maintained at: http://docs.servicestack.net/release-notes-history
Related
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.
I am developing a winform application.I want to provide support for Dropbox in my application. Since my application is .net 3.5 based. I can't use the Dropbox SDK. So, I will be using the rest API. But there are two sets of Dropbox API V1 and V2 for Dropbox. So, are V2 API's stable enough, so that I develop my application using them or should I use the V1 API's.
Answering your question is not that easy since you have to factor in a number of considerations you do not provide information on. Skill level, product time constraints etc all play a role here.
That being said, I have used API V2 but there are some teething issues at times and support / updates are not always lighting quick. API V1 on the other hand have plenty of examples and community support is readily accessible. So my answer would be to use V1 if you favor stability and support over being on the latest release. Even if you use V1 I dont believe you have to fear the API being depreciated very soon, Dropbox has in the past given plenty of notice before they drop support for a API version.
How can I integrate the SignalR references and Dlls into a 3.5 project ?
Three options:
you don't use it
you upgrade your project to a more recent framework (presumably 4.5)
you do the work to make SignalR work on .NET 3.5, possibly submitting a pull request
The web world moves rapidly; .NET 3.5 was released in November 2007 - over 5 years ago. Forcing all library authors to restrict themselves to this, when the vast majority of projects are going to be for 4.0 / 4.5 is prohibitive. Some projects may choose to do this, some may some may offer a restricted subset of features on older platforms, and some may elect that it simply isn't worth the overhead to support (a lot of effort, to support a marginal and declining user base).
Frankly, I think you should treat this as a reason to consider upgrading framework.
In particular, I can imagine SignalR wanting to make use of the WebSocket and improved async IO features, the MVC hooks, plus the http-context stubbing features (for unit tests). But possibly a lot more (I haven't checked).
I m working on a facebook ap with Facebook C# SDK and MVC 3.
One of the problem I m having is: multiple versions of Facebook SDK API with several inconsistent versions. Almost every version there is a change in the API and something that works in one version doesnt work in another. There are also major changes between API versions.
I m using the latest version. (6.0.12). I cant find any documentation on how to use the API.
API website has lot of TODO pages. (http://csharpsdk.org/) and documentation is not concise.
Should I use another SDK ? What do you recommend? or are there any samples I can use for this version?
Thanks.
I'm much in the same boat as you.
I've followed the blog posts from the members of the Facebook c# SDK team, and their reasoning behind doing the latest major re-work of the API. I'm optimistic and think it's a healthy decision, leveraging the majority of the work from the server to the client instead.
In the end, I think it will benefit our applications with a much more scalable and performant solution than before with the earlier SDK. A good thing if your application gets viral.
The earlier versions had good and plenty samples and documentation, I only hope that in time the team will be able to provide that with the newer version as well.
For me, I currently have a v5.0x solution in prod, and I'm very eager to jump on the newer SDK, but I'm holding on for good samples as well, hoping for some magic during the upcoming months.
It's really a question on how long you can wait, I think it's the best SDK out there at this point.
If anyone is having problems with FB breaking old versions like I did, here is a small and brief tutorial I created
http://theocdcoder.com/tutorial-integrating-facebook-authentication-asp-net-mvc-3/
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why should I upgrade to c# 4.0?
Our projects are currently all C# 3. If we dont have a specific requirement for features that C# 4 provides, would there be any other reasons for us to upgrade? Thanks.
Edit
There seems to be more of an advantage with using the new CLR and not just the new language features.
I personally don't feel that there are great language enhancements between C#3 and C#4 if you're targeting the same framework (2.0-3.5).
However, if you move to .NET 4 CLR as well, I think there are all sorts of benefits in the runtime you can take advantage of. My favorite feature is the parallel task library.
It depends on what you want to do. I don't there are killer language features that 2.0 (Generics) and 3.0 (LINQ and Lambdas) had. C# 4 is more scenario based (see list below for some). If you want to:
take advantage of the new features in WCF (default endpoints, improved WCF REST support, etc.);
work with Entity Framework 4 and it's new features along with WCF Data Services to expose your EF model as a data service;
take advantage of some of the multi-threaded enhancements (e.g. Tasks instead of using Threads);
CodedUI tests (more of an IDE thing, not a language thing);
etc.
...then maybe I would. (Most of my projects utilize WCF in some way, so I'm in the process of upgrading.)
I wouldn't upgrade just to upgrade. Upgrade if you have a business/technical reason to do so. You have to weigh the costs (less time coding while you upgrade your environment) with the benefits (latest language, and as one commenter said, happier developers).
Plus, the IDE is nice (although I've found it a little unstable at times). And as w69rdy's comment said, it's backwards compatible. You may want to give the IDE a try and still stay on .NET 3.5 just to try some of its features (like the extension manager and schema comparer).
If your software is fairly static and business critical then an upgrade may present a risk to the production uptime of the business. However, if you plan to continue development of the business' software well into the future then at least planning to upgrade is a step in the right direction. There's no reason to limit one's development to older versions if the company wants its code to keep moving forward. Future problems may have easier and more expressive solutions using newer language capabilities.
There's also certainly something to be said about keeping one's development staff current on technologies. If the business wants its technologies to remain static, it's going to have an increasingly difficult time finding talent over the years.
If upgrading to C# 4 is not a vey large pain for your system, then it's worth it just to have you projects on the new runtime, if .NET 4 were running on .NET 2 like .NET 3.5 is I would say don't bother, but the benefits of being on the newer runtime are futuresafety in this case since there will be future .NET releases based on the .NET 4 runtime, and the upgrade may be more difficult come that time.
I am making the assumption that you're asking if it's worth it when you don't need it because it wouldn't be extremely difficult for you to upgrade, if it would present particular risk and difficulty in your project then it would not be advisable without a sufficient business need for the functionality in .NET 4
If you are using ASP.NET WebForms it might be worth. Take a look at this blog entry.
Web.config files are much cleaner now and css support was enhanced a lot. WebForms Routing is also a core feature under 4.0. Best of all, you finally get full control over your control id's!
In my opinion, WebForms still isn't as nice as ASP.NET MVC, but it got much required love in 4.0.