I am working on a Project which is Using Socket-io library for WebSocket Implementation. So, basically the library that my server is using and the library that I have used in Front-End both have different versions. So, I am confused that is it fine or I should use the same version for both. Also, which one is Appropriate?
You will need to use the same version on both sides. You can review the migration section of the socket.io docs with the breaking changes from version to version. See links below:
2.x -> 3.0
3.x -> 4.0
Related
I plan to use the Microsoft.Azure.NotificationHubs to push notification through Azure notification hub in backend service of an existed project. However, I found that the project is using .NETFramework 4.5.2. As the document stated, the SDK has dependecy to .NETFramework 4.6.1 or higher.
Since the existed project is already developed well and problems could appear if I upgrade. Any other solutions please?
Due to you don't want to upgrade to .Net Framework 4.6.1 or higher. You can use REST API, create HttpClient in your existed project to send Http Request.
（notificationhubs）REST API methods
You can use HttpHelper in my sample code.
i am currently using Restclient to send request via web api for xamarin, it works well with windows and ios but i doesnt work for andriod , i searched and found a nuget package that will help, called ModernHttpClient,so it changes my code from var httpclient = new HttpClient(); to var httpClient = new HttpClient(new NativeMessageHandler()); but when i install it for the web application i keep getting an error stating the package is not compatible with the project. but it installs ok in android,ios and windows. i tried uninstalling it from the web application but i doesnt work in the code unless it appears in all the project.
so i want to find the reason why the package is not compatible with the web appication or a solution to the Restclient request not working on android .
Unfortunately the product page for modernhttpclient on nuget.org doesn't list any dependencies, but changing the domain name of the URL to use fuget.org instead of nuget.org lists monoandroid, monotouch, portable-net45+winrt45+wp8+wpa81, and xamarin.ios10. Therefore, these are the target frameworks that the package supports.
Another way to check what TFMs (target framework monikers) a package supports is to find/download the nupkg and then open it as a zip file, or use NuGet Package Explorer to look for subfolders under lib/.
You didn't say what target framework your web app is using, but this is where things start getting very complicated and I don't understand it very well. .NET Framework TFMs are compatible with other .NET Framework TFMs of lower versions. Similarly .NET Core TFMs are compatiable with other .NET Core TFMs of lower versions. .NET Standard is a whole other complication. NuGet also supports fallback or alternate TFM compatibility, to allow .NET Core apps to use libraries targetting .NET Framework, but it's a best guess and might fail at runtime (maybe it's even possible to fail to compile, I'm not sure, but restore will succeed with a warning). Given you're not getting the warning, but instead an error, it suggests to me that portable-net45 is not compatible with net45 and therefore probably isn't compatible with whatever target framework you're using with your web app (unless your web app is targetting net40 or earlier).
Having said all that, when I was looking at the package to see which frameworks it targets, I saw that the whole point of the package is to use the platform native HTTP stack, instead of Xamerin's HTTP stack on the mobile platforms. Your web app isn't running on a mobile platform, it's running on either .NET Core or .NET Framework, so you shouldn't need the package. I suggest you use #if, #else and #endif to use NativeMessageHandler only on Android and IOS, and then use the default HTTPClient constructor (or use HttpMessageHandler) on other platforms.
I had written a library and published it as a jar. Other applications used my library and everything was great.
Now the other application upgraded their dependencies. and now when they run. the application crashes when it calls my library. It seems that the application now depends on netty 4.1.8 whereas my library depended on a third party library which used an older version. Now when building the other application, sbt evicts my netty version with the newer one. The newer netty version does not have the method on which my code depends upon.
Thus the exception
org.jboss.netty.handler.codec.http.HttpRequest.setHeader(Ljava/lang/String;Ljava/lang/Object;)V"
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.construct(NettyAsyncHttpProvider.java:693)
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.buildRequest(NettyAsyncHttpProvider.java:650)
com.ning.http.client.providers.netty.NettyConnectListener$Builder.build(NettyConnectListener.java:144)
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.doConnect(NettyAsyncHttpProvider.java:1070)
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.execute(NettyAsyncHttpProvider.java:935)
com.ning.http.client.AsyncHttpClient.executeRequest(AsyncHttpClient.java:499)
dispatch.HttpExecutor$class.apply(execution.scala:47)
dispatch.Http.apply(execution.scala:12)
dispatch.HttpExecutor$class.apply(execution.scala:42)
dispatch.Http.apply(execution.scala:12)
scalaxb.DispatchHttpClients$DispatchHttpClient$class.request(httpclients_dispatch.scala:21)
scalaxb.DispatchHttpClients$$anon$1.request(httpclients_dispatch.scala:6)
scalaxb.SoapClients$SoapClient$class.soapRequest(soap12.scala:41)
scalaxb.SoapClients$$anon$1.soapRequest(soap12.scala:23) scalaxb.SoapClients$SoapClient$class.requestResponse(soap12.scala:60)
scalaxb.SoapClients$$anon$1.requestResponse(soap12.scala:23)
I am already using the latest version of the 3rd party library (scalaxb) which depends on old netty.
This is really killing because my library is holding back the entire upgrade process of the application.
There isn't much you can do about this, aside from telling that application's maintainers that using your library requires that specific version of netty, and is not compatible with newer versions. They have to either downgrade back or replace you library with something else.
Can I expect that I replace the Java .jar files and client-side .js files of version 2.4 or 2.5 of CometD in an existing software that is running fine, with the same files in 2.9.1 and it all runs the same?
1- Are the API of CometD exactly the same on all 2.x versions?
2- Is there an upgrade guide that I can use?
Also, I noticed that on the client side, CometD 2.4/2.5 is not AMD and is a single file, but on 2.9.1 it is AMD-based. Is there a single .js file that contains all client-side CometD code?
You can expect upgrades from 2.4/2.5 to 2.9.x to be either without problems, or requiring very little changes, so yes, it should be typically be a drop-in replacement.
While you're upgrading, I suggest to move to CometD 3. You can find here the migration guide from CometD 2.x.
CometD 2.9.x is AMD compliant, and the single file you should include in your HTML is typically org/cometd.js along with a binding for a toolkit (either jquery or dojo).
If you use extensions, you should add also those, see for example http://docs.cometd.org/3/reference/#_primer, or if you don't want to use Maven, this other section.
Follow also the tutorials, that should get you going.
Full documentation link.
Are there any issues with having some apps utilizing EL 4.1 and some 5? Meaning if I decide that a new app will use 5.0 and the majority of the web apps existing is using 4.1, when I deploy to production or even in any situation would there be conflicts or problems if you have apps using different versions?
You cannot use multiple versions in the same application, but I have never had an issue using multiple versions of Enterprise Library in separate applications. There is only one thing I can think of that you might need to watch out for. If any of the web applications using the new version is a child of another using the old version, you might run into some issues due to configuration inheritance.