Thanks for the feedback Tim. We're relatively new to the community so it's very much appreciated.
We had planned to setup the 2017 project files to automatically pull in the NMS and AmqpNetLite packages via NuGet. So there shouldn't be a need for those planning to build this project to build the dependencies. I'd expect this to be the "normal" path most would follow, but of course wouldn't preclude anyone from building all of the dependencies. My view on this would be that it is a bit off of the beaten path though, so if there were a few hoops to jump through, it would be ok. Does that make sense? Thanks, Duane On Thu, Feb 15, 2018 at 3:54 PM, Timothy Bish <[email protected]> wrote: > 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/ > >
