WinRT/Windows Store support

[raffaine]

Guys,

I'm in some kind of trouble ... I don't know how to solve it. The problem is I'm building a Metro Style app with RabbitMQ.Client.Dll and when I try to instantiate a IBasicProperties or use BasicPublish the source stop compiling with the following error:
1>e:\Julio\Projetos\GitHub\RabbitMQ.Client.dll : error CS0011: The base class or interface 'System.ICloneable' in assembly 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' referenced by type 'RabbitMQ.Client.IContentHeader' could not be resolved

Read somewhere that this is because ICloneable doesn't exist anymore on WinRT.Should be useful to build full Win Store apps using RabbitMQ.

[raffaine]

Well, actually it worked for me with a tiny change on source ... I've removed ICloneable inheritance on IContentHeader and added manually the method object Clone() .... and I successfully send a message with a reply_to and received my answer.

All I can say is ... RabbitMQ working fine in a Windows Store App!!!

I don't know very much about pull requests ... and I have not made a full test to commit myself the change ...

[ashwathpro]

Hey raffaine, even I am facing the same issue. Can you tell me how you removed the inheritance and how you manually added the Clone() method?? I am using VS2012. Did you edit the .dll file itself? Please respond as early as possible.

Thanks in advance.

[raffaine]

Hi,

I edited only the file IContentHeader.cs, removing all inheritance and
added only one method:

object Clone();

And it worked.

On Sat, Feb 2, 2013 at 8:33 AM, ashwathpro [email protected] wrote:

Hey raffaine, even I am facing the same issue. Can you tell me how you
removed the inheritance? I am using VS2012. Did you edit the .dll file
itself? Please respond as early as possible.

Thanks in advance.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-13027544.

Julio Cezar Novais Raffaine
Sistemas de Engenharia, Odebrecht SA
São Paulo, SP
http://elloxas.blogspot.com/

[michaelklishin]

Is this still relevant with master/3.4.4?

[ngbrown]

I wasn't part of this issue, but I had separately developed a WinRT branch and discussed it on the mailing list on June 10, 2014.

The approach I had at the time wasn't fully integrated into the nuget packaging, so this effort really depends on #32. I am planning on rebasing my work to the most recent codebase and would like to have it as part of the official release.

I need to know more about the CI environment that is used to build this library. Supposedly, http://www.appveyor.com/ (which is free for OSS projects and has nice integration with GitHub) can build Windows 8.1 Windows Store app packages on Windows Server 2012 R2, but I thought that a client SKU was needed.

[michaelklishin]

@ngbrown we use Windows 7 for building, as well as

• VS 2013 Community edition
• .NET 4.0 or 4.5
• Cygwin (make and openssl are key for this particular repo)

the rest of the testing process currently depends on rabbitmq-public-umbrella but it isn't particularly sophisticated.

Can we add WinRT support without moving to Windows 8.1? (which we can do but we just finished moving to 7 and would need to ask for 8.1 licenses to be procured, worry about VM provisioning on 8.1, etc).

[ngbrown]

A WinRT library requires Windows 8.1 to build. It won't even load on Windows 7. Now Windows 7 can compile a portable class library (PCL) but that doesn't include Socket and TcpClient.

The end result should look something like what AutoMapper does with building a PLC library and also building targeted libraries for each platform. Using the "bait-and-switch" technique, the targeted library with the actual implementation is selected by the tooling for the final application linking. (link and link).

[michaelklishin]

@ngbrown I'd need to do some research on that but I'm guessing that the answer is "we can support WinRT and still build/run tests unrelated to it on Win 7 with some clever tricks". Is this correct?

[ngbrown]

There's no tricks that I know of to build the networking portion on Windows 7. StreamSocket is only on Windows 8 or Server 2012.

There are some differences that I don't think you would want to paper over with a compatibility layer (which would still need compiled on Windows 8/2012, but maybe on another CI platform). This is what the compatibility layer would need to take care of:

• It would need to handle the socket differences and could cover both StreamSocket and TcpClient. The client support for SSL/TLS does not include the ability to use client certificates.
• Also AppDomain unloading is different, in that the Windows 8 application sends a suspending event, not a DomainUnload event.

[michaelklishin]

@ngbrown OK, so what are our options then? Drop Windows 7 support?

[ngbrown]

@michaelklishin no dropping of any support... Just adding. Windows 8 is highly compatible in terms of what desktop applications it runs. For example, you could run your current build process as-is and get the same outputs.

I am suggesting using the NuGet support for multiple framework versions and profiles to include additional dll's for new profiles. For example, the AutoMapper OSS project I mentioned earlier has 11 separate targets in its build script that are combined into a single .nuget package. Check out the authors' blog post on this.

The differences mentioned above with StreamSocket and TcpClient are limitations on the specific .Net profile that a Windows Store Application uses. These are the new full-screen immersive apps and are now the 'Universal App' that also runs on Windows 8.1 Phone. They are build for a newer Windows API, so require different networking code from a library such as the RabbitMQ client. Standard desktop apps wouldn't use that API, and would continue to use the existing framework and TcpClient.

By using the same files, and including preprocessor directives like #if NET45, #if MONO, or #if NETFX_CORE, we can build outputs for additional platforms and framework versions.

[michaelklishin]

@ngbrown excellent, thank you for the detailed reply. We'll do what you suggest and now it should be much easier for you to help us ;)

[michaelklishin]

This is now in master. we still have to fix #82 and evaluate how we'd like to distribute the two versions but if all you need is a WinRT-compatible .dll, you can build and use one today. Huge thanks to @ngbrown for his enormous contribution!