Not compatible with Universal Windows application. about clrzmq4

[metadings]

Well, you should make this "compatible" for universal Windows applications. The nuget package won't help you, so you have to use git clone https://github.com/zeromq/clrzmq4, open the project and build it againt UAP. You may also rebuild the projects zeromq/libzmq, jedisct1/libsodium and steve-o/openpgm, to run them on VS2012 or the current "universal" Windows runtime.

[AmanJangra]

I tried building it and referencing it in a uwp app but the problem is that clrzmq4 targets '.NETFramework' while UWP targets '.NETCore'. Is it possible, by some means, to change the target for clrzmq4 with rewriting minimally ? All I can think of is thinking of building it as a portable library. I just need some advice on how should I proceed. Integrating with Android and IOS was not that complicated but, using it in windows phone app has literally drained me.

[metadings]

Yes, basically you just need to change the compilation target...

(Visual Studio -> Project's Properties -> ".NET Core" instead of ".NET Framework 4")

[AmanJangra]

It's not that straight-forward. I can change target to other versions of the '.NETFramework' but not '.NETCore'.https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/This is on Microsoft's site regarding porting to Core but I don't know if it will be of any help in this case without thge support for .Net Sockets library in the .NETCore.

Following namespaces are not present which are used in clrzmq4:
Microsoft.Win32.SafeHandles.SafeHandleZeroOrMinusOneIsInvalid
System.AppDomain
Most of the System.Delegate
Most of the System.Environment
System.ICloneable
System.IO.Stream
Most of the System.IO.StreamReader
System.PlatformID
Most of the System.Reflection.Assembly
System.Reflection.ImageFileMachine
Most of the System.Reflection.Module
System.Runtime.ConstrainedExecution.Cer
System.Runtime.ConstrainedExecution.Consistency
System.Runtime.ConstrainedExecution.ReliabilityContractAttribute
Most of the System.Runtime.InteropServices.SafeHandle
System.Runtime.Serialization.SerializationInfo
Most of the System.Security.Cryptography.RandomNumberGenerator
System.Security.Cryptography.RNGCryptoServiceProvider
System.Security.Permissions.SecurityAction
System.Security.Permissions.SecurityPermissionAttribute
System.Security.UnverifiableCodeAttribute
Most of the System.Text.Decoder
Most of the System.Text.Encoder
Most of the System.Text.Encoding
Most of the System.Threading.Thread
System.Type

Most of them have replacements. So I am going to modify the code accordingly.

[metadings]

OHA :-) Ya, yes :-) You need a new project file ZeroMQ.core.csproj or the like...

For example: in Visual Studio Code you go creating a new Project, adding all the files and well... see what classes you can replace... (I'm actually very interested in what they did with Delegate, DllImportAttribute, System.Reflection.Assembly, Cryptography.RNG, System.Threading.Thread, System.Text.Encoding and hehe, you know) 👍

[AmanJangra]

Hey Metadings, I have changed most of the code but still I am too far as I have just resolved the easier ones.

UnmanagedLibrary :
SafeLibraryHandle

These are the main classes that are bugging me. What should I do for them? Do I have to write the parts of these classes that are used in zmq on my own and than change the zmq source accordingly. What is the level of difficulty in doing so and Is it the correct way to do?

[metadings]

This class is just used instead of an IntPtr - to hold a handle - and to Dispose or Finalize this really.

So basically we could get rid entierly of this class... You may try this:

Platform.Win32.cs

        [DllImport(LibraryName, CharSet = CharSet.Auto, BestFitMapping = false, SetLastError = true)]
        private static extern IntPtr LoadLibrary(string fileName);

Platform.Posix.cs

        [DllImport(__Internal, CallingConvention = CCCdecl)]
        private static extern IntPtr dlopen(IntPtr filename, int flags);

Then get rid of class SafeLibraryHandle and class SafeLibraryHandles, in favor of just an IntPtr.
There are also places where you have to replace !handle.IsNullOrInvalid() with handle != null || handle != IntPtr.Zero...

And finally in UnmanagedLibrary.cs, try this one:

/// <summary>
/// Utility class to wrap an unmanaged shared lib and be responsible for freeing it.
/// </summary>
/// <remarks>
/// This is a managed wrapper over the native LoadLibrary, GetProcAddress, and FreeLibrary calls on Windows
/// and dlopen, dlsym, and dlclose on Posix environments.
/// </remarks>
public sealed class UnmanagedLibrary : IDisposable
{
    private readonly string TraceLabel;

    private readonly IntPtr _handle;

    internal UnmanagedLibrary(string libraryName, IntPtr libraryHandle)
    {
        if (string.IsNullOrWhiteSpace(libraryName))
        {
            throw new ArgumentException("A valid library name is expected.", "libraryName");
        }
        if (libraryHandle.IsNullOrInvalid())
        {
            throw new ArgumentNullException("libraryHandle");
        }

        TraceLabel = string.Format("UnmanagedLibrary[{0}]", libraryName);

        _handle = libraryHandle;
    }

    /// <summary>
    /// Dynamically look up a function in the dll via kernel32!GetProcAddress or libdl!dlsym.
    /// </summary>
    /// <typeparam name="TDelegate">Delegate type to load</typeparam>
    /// <param name="functionName">Raw name of the function in the export table.</param>
    /// <returns>A delegate to the unmanaged function.</returns>
    /// <exception cref="MissingMethodException">Thrown if the given function name is not found in the library.</exception>
    /// <remarks>
    /// GetProcAddress results are valid as long as the dll is not yet unloaded. This
    /// is very very dangerous to use since you need to ensure that the dll is not unloaded
    /// until after you're done with any objects implemented by the dll. For example, if you
    /// get a delegate that then gets an IUnknown implemented by this dll,
    /// you can not dispose this library until that IUnknown is collected. Else, you may free
    /// the library and then the CLR may call release on that IUnknown and it will crash.
    /// </remarks>
    public TDelegate GetUnmanagedFunction<TDelegate>(string functionName) where TDelegate : class
    {
        IntPtr p = Platform.LoadProcedure(_handle, functionName);

        if (p == IntPtr.Zero)
        {
            throw new MissingMethodException("Unable to find function '" + functionName + "' in dynamically loaded library.");
        }

        // Ideally, we'd just make the constraint on TDelegate be
        // System.Delegate, but compiler error CS0702 (constrained can't be System.Delegate)
        // prevents that. So we make the constraint system.object and do the cast from object-->TDelegate.
        return (TDelegate)(object)Marshal.GetDelegateForFunctionPointer(p, typeof(TDelegate));
    }

    ~UnmanagedLibrary() { Dispose(false); }

    public void Dispose() { Dispose(true); }

    protected virtual void Dispose(bool disposing)
    {
        if (_handle != null && _handle != IntPtr.Zero)
        {
            Platform.ReleaseHandle(_handle);
        }
        GC.SuppressFinalize(this);
    }

}

... and replace every SafeLibraryHandle with IntPtr.

[metadings]

Sorry, I can't edit, I'm using slowed HSDPA connection, and GitHub always reloads every css and script, even if 304 Not Modified.

There are some errors in the code from above; I hope you get it :-)

[AmanJangra]

First of all, Thanks.

Yes I get that. I was just rectifying those along with a couple of hundreds more to go. It doesn't even have threads now. I spent the last few hours replacing threads with running the methods async. I still don't know after changing so much, will clrzmq behave like it should. Thread is just a small part I think I have modified (and commented) a lot.
System.Security.Permissions too not available.
All lib classes and ZException and ZError need to be modified almost completely and ZFrame in bits and parts.

[metadings]

Oh no, don't use async/await. I hate this - because every Delegate could have two extension methods - Async and Await, which are doing basically the same as you do in C#'s async/await. But this critic is theory, so...

Could you revert this to use real Threads instead?

If not, please just continue, I'm curious what you did to the code...
If you could upload this to your github, I'll look over it!

[AmanJangra]

We can not use conventional threads in UWP. For multi threading, it has a Threadpool class which uses Async.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465290

[metadings]

Ah, okay

[metadings]

Moving discussion to Issue #71 .NET Core compatibility.

[sigiesec]

I don't quite understand why you say the discussion is moved to #71. Aren't these different issues? However, I still think this issue (UWP) is not really possible to "support" in clrzmq4, which is a wrapper for the Win32 libzmq.dll. UWP does not allow the use of Win32 DLLs, but would require a WinRT version of libzmq. I am not sure if that, if it would be done, could be wrapped in a similar way as the existing libzmq.dll