[rabbitmq-discuss] Would like to start merging .NET client for WinRT (Windows 8 Store App) with mainline code

[Nathan Brown]

> NUnit was able to test it without the configuration part. I can
> remove that and remove all the MSTest changes. The test runner
> then works as a desktop process (on Windows 8/Server 2012).

I merged with the most recent default branch to eliminate the protocol
configuration stuff and moved to a NUnit project for testing the WinStore
library.  I also backed out the MSTest changes.  This is all pushed to
Bitbucket.

There is a gotcha in that accessing the "Application.Current.Suspending"
event in ConnectionBase throws an exception when not in a full screen XAML
context.  This is equivalent to the AppDomain DomainUnload event, also used
in ConnectionBase.  My solution was to catch and ignore the exception for
the unit test.  An alternative could be to have an "ApplicationEventSource"
class that is implemented/overridden per platform and/or context.

Let me know when you have a chance to test it and if you have any
additional feedback for me.

Thanks,
Nathan Brown



On Mon, Jun 9, 2014 at 3:18 PM, Michael Klishin <mklishin at gopivotal.com>
wrote:

> On 10 June 2014 at 01:48:41, Nathan Brown (nathan at nkbrown.us) wrote:
> > > > Good question. If WinRT is an incompatible target, does it
> > mean
> > > there should be 2 packages, X and X-winrt, for example?
> >
> > Different platform DLLs go in a named folders inside of the NuGet
> > package. Everything is delivered together and Visual Studio
> > links to the correct DLL. If it was possible to build the NuGet
> > package as part of the CI process, that would be the best. Currently
> > the NuGet creation lives elsewhere and is manually populated
> > with the release binaries.
>
> I'll ask our NuGet package maintainer to chime in. I suspect it's time to
> open source the code used for NuGet packaging ;)
>
> > > Is it technically possible to run the current NUnit test suite
> > > on WinRT? Protocol configuration is removed in default and
> > 3.4 will only
> > > support one protocol (0-9-1). Do we still need to worry about
> > using MSTest
> > > then?
> >
> > NUnit was able to test it without the configuration part. I can
> > remove that and remove all the MSTest changes. The test runner
> > then works as a desktop process (on Windows 8/Server 2012).
>
> Excellent!
>
> > > If your branch is in Mercurial or Git somewhere, we can work on
> > it until it's
> > > mostly done, then create a bug and pull it into the mainline.
> >
> > Anyone can pull it from Bitbucket(
> https://bitbucket.org/nathanbrown/rabbitmq-dotnet-client)
> > right now. I can continue to work there.
>
> Lets do that. A public Mercurial repo is all we care about when it's time
> to merge.
> --
> MK
>
> Software Engineer, Pivotal/RabbitMQ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140610/44ae0668/attachment.html>