On 02/15/2018 11:57 AM, Duane Pauls wrote:
In particular, I think we are wondering whether it would be considered
feasible to work towards an initial release with the VS2017 project and
solution files. This would require those who want to build it to either
use VS2017 to build, or to use the dotnet sdk tool, as is described in the
'Building' section of the README.md.
If not considered a gating item for release, we would definitely consider
it as a future enhancement if this would be perceived to be of value.
Cheers,
Duane
On Wed, Feb 14, 2018 at 5:28 PM, cmorgan <[email protected]>
wrote:
Hi everyone,
Tim's post about not having a platform to run Visual Studio 2017 recently
sparked a discussion between Duane, Ragnar and I about adding project and
solution files for older versions of visual studio to the NMS AMQP Provider
and were looking for guidance.
Currently, the project only contains visual studio 2017 project and
solution
files. This was chosen among other things to, 1) reduce the number of of
project files by using the new csproj format multi-target framework
capabilities, and 2) leverage the nuget package integration in the new
csproj format. Other providers seem to contain whatever visual studio files
they need to build. There were two points of discussion that we are
looking
guidance in.
1) Is visual studio 2017 too new to expected a wide variety of developers
to
be able to pickup and look at this project? Does anyone have any insight
into this?
2) Is there an automated system that depends on building tools that predate
visual studio 2017 equivalent build tools? Would it easier for CI builds if
there were project/solution files that can be built with tools the predate
vs2017? If this is not the right place to ask this, then where should I ask
this?
Based on the feedback from the above two points we'd like to come to a
decision on adding project/solution files for previous Visual Studio
versions for initial release of the new AMQP Provider.
If anyone has any question about this please let me know.
Chris Morgan
I don't think there's anything inherently wrong with only including
VS2017 solution files if that' the tool you are using right now for
development. In the end some things would need to be figured out though
like how someone builds it and package it from the CLI if possible as
that is the current workflow for the other NMS libraries although they
are using Nant which is pretty much dead at this point.
One thing to look at is the baseline build environment set by the
AmqpNetLite project which your client is leveraging underneath. Does it
use files from an older VS release, it sort of looks like it to me but
I've not messed with Windows or .NET in a couple years now so I'm a bit
out of the loop. If someone needs more tools to build the dependent
library than they need to build the NMS.AMQP library that could be
frustrating to some.
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
