Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.Net Core Support #35

Open
wants to merge 32 commits into
base: master
Choose a base branch
from
Open

.Net Core Support #35

wants to merge 32 commits into from

Conversation

mohaqeq
Copy link

@mohaqeq mohaqeq commented Feb 15, 2017

A .Net Core project added to support .Net Core (.Net Standard 1.6) framework.

@@ -193,7 +197,11 @@ public MqttNetworkChannel(string remoteHostName, int remotePort, bool secure, X5
// in this case the parameter remoteHostName isn't a valid IP address
if (remoteIpAddress == null)
{
#if NETSTANDARD1_6
IPHostEntry hostEntry = Dns.GetHostEntryAsync(remoteHostName).Result;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, it should look like this:

var getHostEntryTask = Dns.GetHostEntryAsync(remoteHostName);
getHostEntryTask.Wait();
IPHostEntry hostEntry = getHostEntryTask.Result;

Copy link
Author

@mohaqeq mohaqeq Feb 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the difference?
I think this is the longest one. Because "Result" blocks the call to get the value of task and "Wait" do the same.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right and I was wrong. Excuse me.

@@ -0,0 +1,4552 @@
{
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should be added into the .gitignore

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

@@ -0,0 +1,18 @@
{
"version": "1.0.0-*",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wrong version

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean it must be "4.3.0.0"?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it must be the same.

},

"frameworks": {
"netstandard1.6": {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why your code depends on netstandard1.6 instead of its previous versions? Now the code is not compatible with previous versions of netstandard.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because they removed the oldest one. I can just back to 1.5.0-rc2-24027. Is it OK?

@dima117
Copy link

dima117 commented Feb 22, 2017

@ppatierno Сould you tell about the state of the porting M2Mqtt project to the .NET Core?

mohaqeq and others added 4 commits February 24, 2017 12:12
Fix Version

Signed-off-by: Hamidreza Mohaqeq <[email protected]>
Signed-off-by: Hamidreza Mohaqeq <[email protected]>
Wrap this.socket.Shutdown in try and catch
Catch unhandled exception
@Ghostbird
Copy link

Ghostbird commented Aug 18, 2017

Note, the M2Mqtt project runs fine on .NET Core 2.0, without any code changes, see my pull request #59

Zdenek_Devaty and others added 2 commits August 18, 2017 18:06
@Ghostbird
Copy link

Ghostbird commented Aug 30, 2017

Why the NETSTANDARD2_0 parts of the code? It works without those. Is it a better way to do it? Is the other way becoming deprecated?
Currently I'm using an my version from #59, which does not include those changes. Should I include them?
EDIT: I guess I can't include them because of licensing issues.

@mohaqeq
Copy link
Author

mohaqeq commented Aug 31, 2017

This was a port for .Net Standard 1.6. I just add the change to support .Net 2.0.

@Ghostbird
Copy link

Ghostbird commented Aug 31, 2017

@mohaqeq I wonder whether those changes were necessary at all. I tried porting to 1.6 too, which involved adding lots of #if NETSTANDARD1_6 directives, to compensate for parts of the .NET framework that were not supported in .NET Standard 1.6

However when I decided to support building on .NET Standard 2.0, I did NOT add || NETSTANDARD2_0 to those directives, because those workarounds were not necessary any more. .NET Standard 2.0 supported all necessary parts of the framework.

Therefore I opted to forego .NET Standard 1.6 support, since 2.0 support did not require any code changes.

So I think adding NETSTANDARD2_0 directives might be incorrect, but I'm not sure. It might be that I did something wrong instead.

@mohaqeq
Copy link
Author

mohaqeq commented Sep 1, 2017

@Ghostbird I didn't try to build on .Net Standard 2.0 without these flags. I just checked that this solution works with .Net Standard 2.0. I will check if it is not necessary.

@mohaqeq
Copy link
Author

mohaqeq commented Sep 1, 2017

@Ghostbird I've checked these flags and they are necessary.

mohaqeq and others added 4 commits September 1, 2017 12:48
Without exception handling, the SendReceive call right after connect can lead the process to use 100% of CPU on the client machine.
Added try/catch to prevent unconstrained CPU usage
mohaqeq and others added 13 commits July 25, 2018 13:04
Fixing issue with long live connections & DNS updates
* Change for ALPN support.
Add property of ALPN protocol names, and add constructor for use ALPN.

* delete useless try-catch.

* add comment about ALPN support

* delete constructor, change alpnProtocols parameter as an optional param.

* update comment about ALPN support.
@floydpink
Copy link

@icraggs - thank you for maintaining this really useful library.

What are your thoughts on getting this PR merged in? Are there any blockers that we need to resolve before this can be considered?

Also, @mohaqeq - thank you for all the work on your fork to port this into .NET Core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants