Enable nuget publishing of Xunit wiring

[mchaloupka]

I have done changes necessary to publish Xunit wiring publishing.

The change is that I am calling dotnet pack on the whole solution. Therefore, I had to mark all the projects as non-packable and only the selected ones are marked as packable. I have extracted shared properties for the to-be published projects to a new props file.

It seems that the pack is now triggering build. Not sure why that happens. It does not matter much in our case so I just ensured that the tests will be executed without building after packing, so it should be running using the packed libraries.

[mchaloupka]

How about putting the two packaged projects into a /src folder (and maybe putting others under /examples) and then putting an <IsPackable>true in that folder's Directory.Build.props ?

You could also inline the bulk of the nuget.props into there

We have also unit tests. I kind of like the explicit approach. On the other hand, the real problem is only with some of the examples project. The unit test projects are automatically marked as not packable. I will experiment with it to remove the need of the extra nuget.props file.

I dont think doing a global pack makes sense, esp when we only have 2 nugets to generate. Here's a way I did it.

Can you elaborate what is the advantage of your approach? To me it feels that it should be preferred to pack in one go, especially as there are references between the projects.

While it'd be ideal to test with identical binaries, in general I think letting dotnet pack and dotnet test both trigger incremental builds is not the end of the world.

Yeah, I believe so.

For the sourcelink, also should add https://devblogs.microsoft.com/dotnet/producing-packages-with-source-link/#deterministic-builds ?

Yeah, why not.

[bartelink]

Can you elaborate what is the advantage of your approach? To me it feels that it should be preferred to pack in one go, especially as there are references between the projects.

Not really ;) The main thing for me is to be able to trigger a given action from the command line and/or from a CI driver consistently.

If I dont have a monolithic fake script, then using the standard SDK-provided dotnet pack etc is that thing.

This allows one to e.g. run the tests on 3 environments, but explicitly trigger the pack only on one.

Of course e.g. the way I have the tests there mean that you dont parallelize the test runs or builds as one can do when you use a .sln (in Equinox I did that: https://github.com/jet/equinox/blob/master/build.proj#L32)

But ultimately it's all subjective - you can achieve the same effects no matter how you do it.

It might be possible to do a dotnet build on the sln and then do a dotnet pack and/or some dotnet tests with --no-build or whatever it is to force it not to rebuild even if ordinarilyit might (e.g. due to settings discrepancies)

[mchaloupka]

It might be possible to do a dotnet build on the sln and then do a dotnet pack and/or some dotnet tests with --no-build or whatever it is to force it not to rebuild even if ordinarilyit might (e.g. due to settings discrepancies)

Yes, and we are not so far from it. It was not originally possible to run dotnet test on solution and that is the reason, why it is so specific now. I believe that with a little of work, it should be possible to run it on solution (just the xunit projects needs to have updated frameworks on non-windows platforms I believe).

[mchaloupka]

For simplicity, I disabled running .net 4 tests under linux. We want to get rid of the framework eventually so it is probably not worth the effort to configure the xunit projects to not target .net 4 on linux.

Anyway, it should be complete. What do you think?

[bartelink]

Yes :shipit: