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'm trying to port SharpRepository to .NET Core, but the unit test project has a dependency on Should. Does the MyGet discussion here mean there's an unofficial, but still publicly available, NuGet package that supports .NET Core now? https://github.com/SharpRepository/SharpRepository/issues/136

[alski]

Hi, I'm not completely sure what the .NetCore requirements are, but I made the switch over to the TypeInfo methods https://github.com/dotnet/apireviews/tree/master/2016-01-19-reflection in order to support UWP. Hopefully that's the bit you need.

My current plan is to only make changes here so that this fork is supported under a MyGet build. I'm hoping that this will make it very simple for @erichexter or whomever to pull in the changes as it appears that the main branch is built that way (https://www.myget.org/gallery/should).

[erichexter]

@alski the dlls are built on the codebetter team city server then pushed to myget. So you do not need to get the myget build working.

[eloekset]

@alski I hope it is of interest for this PR, if not I'll move this question to some other forum.

I'm not sure how to structure the Should NuGet package to work with the netstandard1.3 profile. I'm still confused about the effect of defining the various new framework profiles in a project.json. Anyway, I have to reference it as a NuGet package, or include the Should project(s) in the SharpRepository solution. I would prefer having a local folder NuGet repo with the (so far) unofficial Should.2.0.0.1.nupkg and reference it that way. Trying to ask about this on Twitter as well: https://twitter.com/eloekset/status/757643549601046528

How did you decide to use the netcore45 profile for Should, v.s. for instance netstandard1.0? Do you know of a good guide on this? The best I've found is this: https://docs.microsoft.com/en-us/dotnet/articles/core/packages#frameworks and this: https://docs.microsoft.com/en-us/dotnet/articles/core/porting/libraries#targeting-the-net-standard-library

For SharpRepository I decided to use (or at least start with) netstandard1.3, since that aligns with .NET 4.6, if I've understood it correctly. In the project.json I've defined both net451 and netstandard1.3. Anyway, I can't understand why I'm not able to install the Should.2.0.0.1.nupkg after I've faked both netstandard1.0 and netstandard1.3 support (see screenshot in tweet).

[alski]

@erichexter I am happy to get this working in anyway that is best for the long term. I had assumed that you were using MyGet build services and then pushed into NuGet.org from there.

However the more time I spend with the NuGet Packager the less likely I think it will provide a multi-platform no-touch solution going forwards. I think an alternative to that is probably better. The MyGet build services seem to provide a lot of the support for auto incrementing version numbers (in assemblyInfo and .nuspec) so I was planning on utilising that.

[alski]

@eloekset I went with netcore45 simply because that was what VS2015 gave me when I asked for a UWP class library. I was trying to make as small a change as possible (!) so that this fork could be pulled back into the main branch, (and I still hope that ;-)).

Personally I see no reason not to produce whatever flavours we need. That is why I have gone to the shared project model. However I would also argue that a better solution might be to produce the portable aseembly e.g. (portable-net45+win8+wp8+wpa81). Your thoughts?

[eloekset]

@alski I'm just not sure what the best approach is. Hope to learn it some time in the near future. 😉

I've pulled down the latest Newtonsoft.Json package, since that's one of the most used NuGet packages, and it seems to support (almost) every framework there is - even .NET 2.0.

I assume James Newton-King has a good understanding of how these profiles work. But according to this table, https://docs.microsoft.com/en-us/dotnet/articles/core/porting/libraries#targeting-the-net-standard-library, netstandard1.0 should work for everything from WP Silverlight 8.0 and up, so for me it looks redundant to specify a folder for all the other frameworks as well.

[erichexter]

@ai I have been using Teamcity to do the build number increment, http://teamcity.codebetter.com/project.html?projectId=Should&tab=projectOverview

Eric Hexter

blog | http://Hex.LosTechies.com info | http://www.linkedin.com/in/erichexter

On Mon, Jul 25, 2016 at 2:37 PM, Al [email protected] wrote:

@erichexter https://github.com/erichexter I am happy to get this working in anyway that is best for the long term. I had assumed that you were using MyGet build services and then pushed into NuGet.org from there.

However the more time I spend with the NuGet Packager the less likely I think it will provide a multi-platform no-touch solution going forwards. I think an alternative to that is probably better. The MyGet build services seem to provide a lot of the support for auto incrementing version numbers (in assemblyInfo and .nuspec) so I was planning on utilising that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/erichexter/Should/pull/11#issuecomment-235060414, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHABGrYwbhnP0ZwliN2E4c6aUUgEvMgks5qZRBogaJpZM4G_NbD .

[alski]

@eloekset Interesting. Looks like portable is separate from netstandard then.

[eloekset]

@alski Maybe, or it might be that he's done that, even if it's redundant, to ensure compatibility with old nuget.exe's around? Maybe we should ask him?

I know I've watched Damian Edwards explain these things in one of the ASP.NET Community Standups, but I can't remember which episode, and it's very difficult to find a specific topic in the recordings (ref https://github.com/aspnet/live.asp.net/pull/92).

[JamesNK]

They're for backwards compatibility.

[alski]

Right. So there is now a working compile, test, pack solution building on the MyGet build services and exposing nupkgs at https://www.myget.org/feed/shoulduwp/package/nuget/Should and https://www.myget.org/feed/shoulduwp/package/nuget/ShouldFluent, containing • .NETCore 4.5: 4.5.0.0 • .NETFramework 3.5: 3.5.0.0 • .NETFramework 4.0: 4.0.0.0

This is accessed by running build.bat in the repo root, so should be portable to any build solution e.g. http://teamcity.codebetter.com.

@erichexter please let me know if there is anything else I can do to get this pull accepted. @eloekset I'm having problems with Update3 and will have to a full VS uninstall and re-install before looking at netstandard, however I suggest we branch to avoid extending this pull any further.

Oh and Thanks to @maartenba for the help with the MyGet platform.

[erichexter]

Let me get this pull landed and work out the build system changes then we can do the branch and look at bet standard, if we need I could ask a dot net team member for some guidence working around the issues you are having

On Tuesday, July 26, 2016, Al [email protected] wrote:

Right. So there is now a working compile, test, pack solution building to https://www.myget.org/feed/shoulduwp/package/nuget/Should and https://www.myget.org/feed/shoulduwp/package/nuget/ShouldFluent, producing • .NETCore 4.5: 4.5.0.0 • .NETFramework 3.5: 3.5.0.0 • .NETFramework 4.0: 4.0.0.0

This is accessed by running build.bat in the repo root, so should be portable to any build solution e.g. http://teamcity.codebetter.com.

@erichexter https://github.com/erichexter please let me know if there is anything else I can do to get this pull accepted. @eloekset https://github.com/eloekset I'm having problems with Update3 and will have to a full VS uninstall and re-install before looking at netstandard, however I suggest we branch to avoid extending this pull any further.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/erichexter/Should/pull/11#issuecomment-235233383, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHABDK7_ZZ9Zii9fc9qlirTqtQ8OuWZks5qZeWQgaJpZM4G_NbD .

Eric Hexter

blog | http://Hex.LosTechies.com info | http://www.linkedin.com/in/erichexter

[alski]

@erichexter Thanks.

[alski]

Hi Eric, We are coming up on the one year anniversary of this pull request. As I stated before I believe everything is in place for it to be adopted.

Right. So there is now a working compile, test, pack solution building on the MyGet build services .... This is accessed by running build.bat in the repo root, so should be portable to any build solution e.g. http://teamcity.codebetter.com. alski commented on Jul 26

Is there anything else I can do to assist in getting it fully merged?

[erichexter]

@alski I am so sorry this slipped through the cracks. I will get this merged soon.

[alski]

Hi Eric, Sorry its been a while since I touched this. However I opened a standard Developer Command Prompt for VS2015 and ran build.bat successfully.

C:\Program Files (x86)\Microsoft Visual Studio 14.0>cd \Dev\Should

C:\Dev\Should>build.bat

C:\Dev\Should>tools\nuget.exe install MSBuildTasks -o .build
Feeds used: https://api.nuget.org/v3/index.json C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Attempting to gather dependencies information for package 'MSBuildTasks.1.5.0.214' with respect to project '.build', targeting 'Any,Version=v0.0' Attempting to resolve dependencies for package 'MSBuildTasks.1.5.0.214' with DependencyBehavior 'Lowest' ..... Lots chopped out here ....

Successfully created package 'C:\Dev\Should\ShouldFluent.0.0.0.1.nupkg'.

EXEC : warning : 1 issue(s) found with package 'ShouldFluent'. [C:\Dev\Should\ms.build]

Issue: Consider providing Summary text. Description: The Description text is long but the Summary text is empty. This means the Description text will be trun cated in the 'Manage NuGet Packages' dialog. Solution: Provide a brief summary of the package in the Summary field. Done Building Project "C:\Dev\Should\ms.build" (default targets).

Build succeeded.

"C:\Dev\Should\ms.build" (default target) (1) -> (Pack target) -> EXEC : warning : 1 issue(s) found with package 'Should'. [C:\Dev\Should\ms.build] EXEC : warning : 1 issue(s) found with package 'ShouldFluent'. [C:\Dev\Should\ms.build]

2 Warning(s)
0 Error(s)

Time Elapsed 00:00:11.20

C:\Dev\Should>

[alski]

Interestingly it also works for VS2017RC but there you can explicitly see it detecting the version of msbuild

---

** Visual Studio 2017 RC Developer Command Prompt v15.0.25920.0 ** Copyright (c) 2016 Microsoft Corporation

---

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise>cd \DEv\Should

C:\Dev\Should>build.bat

C:\Dev\Should>tools\nuget.exe install MSBuildTasks -o .build
Feeds used: https://api.nuget.org/v3/index.json C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

.... snip ....

C:\Dev\Should>tools\nuget.exe restore src\Should.sln MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.

.... snip ....

Build succeeded.

"C:\Dev\Should\ms.build" (default target) (1) -> (Pack target) -> EXEC : warning : 1 issue(s) found with package 'Should'. [C:\Dev\Should\ms.build] EXEC : warning : 1 issue(s) found with package 'ShouldFluent'. [C:\Dev\Should\ms.build]

2 Warning(s)
0 Error(s)

Time Elapsed 00:00:10.85

[erichexter]

@alski I ran this from a clean clone and the build fails on my machine. Here is a link to the build output.

https://gist.github.com/erichexter/2b673eb8d09324f341500b6aade23ca3#file-output-txt-L63

[alski]

@erichexter It appears that at some point I upgraded from msbuildtasks 1.5.0.186 to 1.5.0.214. On my machine, this meant that the old nuget package under .build was still available, but the import directives were unchanged so failed on a clean machine. I simulated this by cleaning up my local .build and re-running. The above patch was then required to get it working again.

Looking at the history of ms.build I can see I added this reference to support the myget build. This support was added solely because I assume you used a myget build engine (as you have a pre-release build at http://www.myget.org/F/should/). However if this is going to continue on with a solely cobebetter build and I see no reason why it shouldn't, then we can possibly drop some of these later changes as I seem to remember that the MSBuildTasks is supplied automatically under the path. Unfortunately there is no Build Log on the codebetter server to verify with, due to its move to jetbrains.

[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.