You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There have been a number of changes to the solution (not the code) recently and for me, somebody with a basic understanding of NuGet for dependency management and a bit of history with managing projects targeted at different environments, things are starting to get a little complicated.
My orignal pull request last year was to try and make the library as accessible as possible. This mean being able to create a NuGet package which can be easily found and used in NuGet. The package has been reasonably successful: http://nuget.org/packages/PusherRESTDotNet (505 downloads at the time of writing)
The recent changes have removed packages.config file and changed the way the the Newtonsoft.json dependency is defined. This means it's more difficult to create a NuGet package and then deploy to NuGet.
Rather than create my own version of the library with a NuGet package in mind I was hoping that I we could gather some feedback about this and come up with a way of structuring the solution so that everybody was catered for:
Those using Visual Studio Express can open and use the solution
Visual Studio 2010 and other professional editions can still use the solution
A NuGet package can easily be built and deployed from the contents of the solution
Dependency management has always been a pain so I personally feel that using NuGet is the best way to go. What are the problems with using NuGet (and therefore a packages.config) when defining project dependencies? Why is it better to have a libs folder?
I'd appreciate the input of @stack72, @ryoe and of course @grahamscott on this issue with a focus on making the solution as accessible as possible whilst maintaining the obvious benefits of making it easy to deploy to NuGet.
The text was updated successfully, but these errors were encountered:
To be honest, when I encountered the "libs" folder not displaying in the VS Express solution, I simply moved them inside the projects. It was quick and "solved" the problem. However, I'd have to agree that the NuGet package is a better way to go overall. I will close my pull request in favor of the NuGet direction.
There have been a number of changes to the solution (not the code) recently and for me, somebody with a basic understanding of NuGet for dependency management and a bit of history with managing projects targeted at different environments, things are starting to get a little complicated.
My orignal pull request last year was to try and make the library as accessible as possible. This mean being able to create a NuGet package which can be easily found and used in NuGet. The package has been reasonably successful:
http://nuget.org/packages/PusherRESTDotNet (505 downloads at the time of writing)
The recent changes have removed packages.config file and changed the way the the Newtonsoft.json dependency is defined. This means it's more difficult to create a NuGet package and then deploy to NuGet.
Rather than create my own version of the library with a NuGet package in mind I was hoping that I we could gather some feedback about this and come up with a way of structuring the solution so that everybody was catered for:
Dependency management has always been a pain so I personally feel that using NuGet is the best way to go. What are the problems with using NuGet (and therefore a packages.config) when defining project dependencies? Why is it better to have a libs folder?
I'd appreciate the input of @stack72, @ryoe and of course @grahamscott on this issue with a focus on making the solution as accessible as possible whilst maintaining the obvious benefits of making it easy to deploy to NuGet.
The text was updated successfully, but these errors were encountered: