Support for Universal Windows Projects via NetCore45

[alski]

Hi Eric,
I was hoping to use Should in a Universal App I was building recently and came across a problem, it wasn't supported.

This pull request is a result of trying to build support for Should on UWP into a Nuget package and as a result it has been quite a journey. Taken in order these commits represent

• Getting code compiling under netCore via #if NETFX_CORE
• Migration to a shared project model (removing the need for ilmerge)
• A failed journey in getting nant to support buiiding netcore45
• migration to what seems to be a well used NuGet packager (https://visualstudiogallery.msdn.microsoft.com/daf5c6db-386b-4994-bdd7-b6cd52f11b72?SRC=VSIDE).
• replacing the entire Nant build with msBuild

There are some minor things still to resolve,

• haven't tried publishing but it looks as simple as adding config to the src\Should.Package\Nuget.config and src\Should.Fluent.Package\Nuget.config for the package source and Api key.
• multiple copies of nuget.exe in the source tree (yes, I'm being picky now).

I hope it meets your standards and you can make use of it, feel free to contact me if you have any questions.

Thanks for producing Should in the first place.

[alski]

Some useful information on the use of TypeInfo methods, https://github.com/dotnet/apireviews/tree/master/2016-01-19-reflection

[andresvettori]

Hi there, there are any plans to accept this pull request and merge these changes to support UWP?
I mean, there are plans to make this support official or we should keep compiling / distributing this ourselves?

[alski]

Andres,
I have spoken to Eric via email, and he did both suggest that he would pull it in when he has the time, and also ask if I could cope with manually compiling for the time being.
As much as I really don't want to end up with a forked library, how about we give it another couple of weeks and then set up a myget and NuGet solution until it is pulled in.

[alski]

[andresvettori]

Thanks a lot for your response, Al. So, you are saying that while we wait fir Eric to merge this into the main trunk you are going to upload your build into a myGet feed? I understood correctly? If that is right then I'm perfectly fine with it, and if not, and I can help in any way please let me know. Again, thanks.

[alski]

Basically yes. Also given that it seems to fail when built with myget, then this might be what is stopping full adoption.

[eloekset]

I've just pulled your latest changes and got some other issue running build.bat. What I see when running in VS 2017 Developer Command Prompt is that it's using 14.0 tools to build (VS 2015) and then the build fails. I haven't bothered installing UWP tools for VS 2017, but I'll do it now to test if that'll fix anything.

[alski]

Excellent, I had that problem too. That was why I was assuming a broken vs install
I've just updated a branch with a hack around it (basically keeping the VisualStudioVersion to 14.0 event for 15.0)

It might be that the UWP support still isn't ready in VS17 and we will have to raise a bug for it. Not seeing anything at the moment though
https://developercommunity.visualstudio.com/search.html?f=&type=question+OR+problem&type=question+OR+problem&c=&redirect=search/search&sort=relevance&q=Microsoft.Windows.UI.Xaml.CSharp.targets

[alski]

@erichexter we've had a good go at making this work today. The fundamental problems will come down to whether the TeamCity build server supports VS2017 yet.

I realise you are busy, so if you want to give me access, I would be happy to set up some branch builds on the TC server
https://teamcity.jetbrains.com/project.html?projectId=Should the same as is now on and we can find out what is supported on the jetbrains opensource/demo platform..
MyGet-VS2015Branch.zip
Localhost-MasterBranch-VS2017.zip

[eloekset]

If the build servers have support for .NET CLI, we could go back to MSBuild 14 and execute a "dotnet build" command from the build script. Since we've got two solutions it should go fine to build Should.sln with MSBuild 14 and Should.DotNetCore.sln with the .NET CLI. Just a thought. I have no idea what's supported in the build environment.

[alski]

That's a nice idea, the nuget pack won't care how the libs get built, just that they are in place.

[eloekset]

@erichexter which one of the build agents is used for this project? The Win10ProX64VS2015i01 one has MSBuild 14 and DotNetCore SDK 1.0.0-preview2 installed: https://teamcity.jetbrains.com/agentDetails.html?id=43514&tab=agentParameters&kind=conf

[alski]

@eloekset Looks like there are 11 agents available on the team city server, 6 of which currently support everything that Should needs https://teamcity.jetbrains.com/viewType.html?buildTypeId=bt657&tab=compatibilityList
The one you mention is one of those, so if we change the should requirements then it will automatically run on that agent.

[alski]

Hi Eric, I recently tried to contact you privately. I've resent tonight, can you let me know if you didn't get the email. Thanks.

[JamesStuddart]

@alski Did you manage to get a version of Should building in .Net Standard?

[alski]

Hi James,
I'm sorry but no I didn't in the end. If I remember correctly the issue is with access to the build service used to produce the binaries and upload to Nuget. I believe Eric needed to confirm he was happy to have the password reset.

[JamesStuddart]

@alski that is disappointing, I guess it a case of building a spin off library then StandardShould :) or something like that

[erichexter]

If you are still interested we can get you up and running on the build server. Eric Hexter blog | http://Hex.LosTechies.com info | http://www.linkedin.com/in/erichexter

…

On Sun, Jun 3, 2018 at 6:02 AM, James Studdart ***@***.***> wrote: @alski <https://github.com/alski> that is disappointing, I guess it a case of building a spin off library then StandardShould :) or something like that — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHABKQ68rXsG_0yapv6pD0d1l8u_zVPks5t48I2gaJpZM4G_NbD> .

[JamesStuddart]

It's been a long time coming, I've only just finally had chance and this evening to sit down and do anything. I have ported the main code to Core 2.2, I've got the unit tests running and I've moved it to xunit rather than nuint.

I need to update some of test where the code is showing warnings, and there are 3 failing unit tests at the moment.

I've not done anything with nant, so no idea if it'll run on a nant build.
You can see it here https://github.com/JamesStuddart/Should

[erichexter]

ok, I am sure we can get something running, its been 7 years since I touched a nant build myself. As long as the build compiles and runs the tests, at this point I do not have any preference with how that gets done.

[JamesStuddart]

@erichexter that's going to be a blast from the past then :)
The three tests that currently aren't passing as exception throwing check from Trace, I haven't had chance to look into it properly yet, as had family stuff to do yesterday.
I'll try and look into it, this evening.