I've a few comments regarding the experience of adding a RavenDB nuget package to a project. Currently, the following dependencies are added to a standard class library project:
My initial impression is the this is a bit heavy especially if one just wants to use IDocumentStore in a few projects in a solution. I consider the RavenDB package to a 'low' level type of library, sort of similar to System.Data(.SqlClient), in that I'd expect and be as self contained as possible.
2) Newtonsoft.Json has types exposed on public api such as JsonContractResolver property on DocumentConvention so not much we can do here. Would prefer my project not to see it to be honest.
3) NLog is what I would consider to be a application level dependency i.e. referenced at the composite root. I'd prefer my projects not reference it directly. Also perhaps may cause problems with different versions or a dev wants to use a different logger. I suggest an ILog interface in Raven.Abstractions and a static LogProvider instead of referencing Nog.LogManager directly in code. Can provide an NLog \ Log4Net adapter seperated or just as documentation for other users to plug in.
5) Debugger visualizer is useful, but would consider putting this in a seperate nuget package for reference by test projects, if so desired.
6) This is dependent on System.Transactions which is not declared in the package's <frameworkAssemblies>. (Will there be a Raven.Client.Heavyweight?)
7) Raven.Client.MvcIntegration - that is only of interest to Mvc projects? Seperate NuGet package perhaps? It is dependent on System.Web and System.Web.MVC which are not declared in the NuGet package <frameworkAssemblies>. Not saying they should be, just saying because...
8) Exposed by attribute on AbstractIndexCreationTask and *is* declared via <frameworkAssemblies>. So, some inconsitencies between 6 / 7 & 8.
In short what I'd like to see, or as close as possible, is just these references added:
1. Raven.Abstractions 2. Raven.Client.Lightweight
You thoughts please?
Btw, I reserve the right to be wrong and of course willing to do any work as a result of this discussion :)
1) We can avoid referencing the AsyncCtpLibrary, I guess. 2) Exposing json.net gives you a lot of power, actually. 3) We can avoid referencing NLog, but I am not going to introducing an abstraction for that. 5) We can do that, yes. 6) We don't need to do that, if you want to use TransactionScope, you'll do that, and we will integrate with that. 7) There isn't a way to add something just to MVC projects, and I want to avoid having bazziliion nuget packages. 8) Yes, that is because this can cause compilation issues, the others do not.
Damian, I will be honest and say that I actually pay very little attention to the way nuget works. Would you be able to send a pull request for those changes? Specifically, 1,5,7 would be great.
On Mon, Feb 27, 2012 at 7:31 PM, Damian Hickey <dhic...@gmail.com> wrote: > Hello all,
> I've a few comments regarding the experience of adding a RavenDB nuget > package to a project. Currently, the following dependencies are added to a > standard class library project:
> My initial impression is the this is a bit heavy especially if one just > wants to use IDocumentStore in a few projects in a solution. I consider the > RavenDB package to a 'low' level type of library, sort of similar to > System.Data(.SqlClient), in that I'd expect and be as self contained as > possible.
> 2) Newtonsoft.Json has types exposed on public api such as > JsonContractResolver property on DocumentConvention so not much we can do > here. Would prefer my project not to see it to be honest.
> 3) NLog is what I would consider to be a application level dependency i.e. > referenced at the composite root. I'd prefer my projects not reference it > directly. Also perhaps may cause problems with different versions or a dev > wants to use a different logger. I suggest an ILog interface in > Raven.Abstractions and a static LogProvider instead of referencing > Nog.LogManager directly in code. Can provide an NLog \ Log4Net adapter > seperated or just as documentation for other users to plug in.
> 5) Debugger visualizer is useful, but would consider putting this in a > seperate nuget package for reference by test projects, if so desired.
> 6) This is dependent on System.Transactions which is not declared in the > package's <frameworkAssemblies>. (Will there be a Raven.Client.Heavyweight?)
> 7) Raven.Client.MvcIntegration - that is only of interest to Mvc projects? > Seperate NuGet package perhaps? It is dependent on System.Web and > System.Web.MVC which are not declared in the NuGet package > <frameworkAssemblies>. Not saying they should be, just saying because...
> 8) Exposed by attribute on AbstractIndexCreationTask and *is* declared via > <frameworkAssemblies>. So, some inconsitencies between 6 / 7 & 8.
> In short what I'd like to see, or as close as possible, is just these > references added:
On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
> 1) We can avoid referencing the AsyncCtpLibrary, I guess. > 2) Exposing json.net gives you a lot of power, actually. > 3) We can avoid referencing NLog, but I am not going to introducing an > abstraction for that. > 5) We can do that, yes. > 6) We don't need to do that, if you want to use TransactionScope, you'll > do that, and we will integrate with that. > 7) There isn't a way to add something just to MVC projects, and I want to > avoid having bazziliion nuget packages. > 8) Yes, that is because this can cause compilation issues, the others do > not.
> Damian, > I will be honest and say that I actually pay very little attention to the > way nuget works. > Would you be able to send a pull request for those changes? Specifically, > 1,5,7 would be great.
On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey <dhic...@gmail.com> wrote: > Sure, should get some cycles to spend on it this week.
> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >> 2) Exposing json.net gives you a lot of power, actually. >> 3) We can avoid referencing NLog, but I am not going to introducing an >> abstraction for that. >> 5) We can do that, yes. >> 6) We don't need to do that, if you want to use TransactionScope, you'll >> do that, and we will integrate with that. >> 7) There isn't a way to add something just to MVC projects, and I want to >> avoid having bazziliion nuget packages. >> 8) Yes, that is because this can cause compilation issues, the others do >> not.
>> Damian, >> I will be honest and say that I actually pay very little attention to the >> way nuget works. >> Would you be able to send a pull request for those changes? Specifically, >> 1,5,7 would be great.
Damian, a short note (and sorry about the lagged response):
5. Debugger visualizer - let's not create yet another nuget package for it, instead just have it excluded from references and anyone who wants that can reference it later on.
On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey <dhic...@gmail.com> wrote: > Sure, should get some cycles to spend on it this week.
> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >> 2) Exposing json.net gives you a lot of power, actually. >> 3) We can avoid referencing NLog, but I am not going to introducing an >> abstraction for that. >> 5) We can do that, yes. >> 6) We don't need to do that, if you want to use TransactionScope, you'll >> do that, and we will integrate with that. >> 7) There isn't a way to add something just to MVC projects, and I want to >> avoid having bazziliion nuget packages. >> 8) Yes, that is because this can cause compilation issues, the others do >> not.
>> Damian, >> I will be honest and say that I actually pay very little attention to the >> way nuget works. >> Would you be able to send a pull request for those changes? Specifically, >> 1,5,7 would be great.
I'm in two minds whether additional packages are worth it or not. The only thing is that if a reference is manually added and the developer updates the package through nuget, those references will have to be re-added manually. You ok with that?
To specify explicit assembly references I have to use nuspec's <reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> element. I can codify this in the build script (default.ps1) or create a separate nuspec for the client. What is the team's preference? Personally, I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a concious decision to do it all in the build script?
I'll do the AsyncCtpLibrary dependency removal on the client in a separate pull request. Heard from a colleague that it was causing a conflict in VS11/.net4.5 too.
On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
> Damian, a short note (and sorry about the lagged response):
> 5. Debugger visualizer - let's not create yet another nuget package for > it, instead just have it excluded from references and anyone who wants that > can reference it later on.
> 7. Ditto
> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>> Sure, should get some cycles to spend on it this week.
>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>> 2) Exposing json.net gives you a lot of power, actually. >>> 3) We can avoid referencing NLog, but I am not going to introducing an >>> abstraction for that. >>> 5) We can do that, yes. >>> 6) We don't need to do that, if you want to use TransactionScope, you'll >>> do that, and we will integrate with that. >>> 7) There isn't a way to add something just to MVC projects, and I want >>> to avoid having bazziliion nuget packages. >>> 8) Yes, that is because this can cause compilation issues, the others do >>> not.
>>> Damian, >>> I will be honest and say that I actually pay very little attention to >>> the way nuget works. >>> Would you be able to send a pull request for those changes? >>> Specifically, 1,5,7 would be great.
On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey <dhic...@gmail.com> wrote: > No problem Itamar, only getting around to it now.
> I'm in two minds whether additional packages are worth it or not. The only > thing is that if a reference is manually added and the developer updates > the package through nuget, those references will have to be re-added > manually. You ok with that?
> To specify explicit assembly references I have to use nuspec's <reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> > element. I can codify this in the build script (default.ps1) or create a > separate nuspec for the client. What is the team's preference? Personally, > I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a > concious decision to do it all in the build script?
Yes, we prefer the have one nuspec file and the build script to do modifications to it.
> I'll do the AsyncCtpLibrary dependency removal on the client in a separate > pull request. Heard from a colleague that it was causing a conflict in > VS11/.net4.5 too.
> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>> Damian, a short note (and sorry about the lagged response):
>> 5. Debugger visualizer - let's not create yet another nuget package for >> it, instead just have it excluded from references and anyone who wants that >> can reference it later on.
>> 7. Ditto
>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>> Sure, should get some cycles to spend on it this week.
>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>> 2) Exposing json.net gives you a lot of power, actually. >>>> 3) We can avoid referencing NLog, but I am not going to introducing an >>>> abstraction for that. >>>> 5) We can do that, yes. >>>> 6) We don't need to do that, if you want to use TransactionScope, >>>> you'll do that, and we will integrate with that. >>>> 7) There isn't a way to add something just to MVC projects, and I want >>>> to avoid having bazziliion nuget packages. >>>> 8) Yes, that is because this can cause compilation issues, the others >>>> do not.
>>>> Damian, >>>> I will be honest and say that I actually pay very little attention to >>>> the way nuget works. >>>> Would you be able to send a pull request for those changes? >>>> Specifically, 1,5,7 would be great.
On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey <dhic...@gmail.com> wrote: > No problem Itamar, only getting around to it now.
> I'm in two minds whether additional packages are worth it or not. The only > thing is that if a reference is manually added and the developer updates > the package through nuget, those references will have to be re-added > manually. You ok with that?
Yes
> To specify explicit assembly references I have to use nuspec's <reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> > element. I can codify this in the build script (default.ps1) or create a > separate nuspec for the client. What is the team's preference? Personally, > I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a > concious decision to do it all in the build script?
The build script is creating the folder structure to pack into nupkg and then it can have list of DLLs we want to explicitly de-reference
> I'll do the AsyncCtpLibrary dependency removal on the client in a separate > pull request. Heard from a colleague that it was causing a conflict in > VS11/.net4.5 too.
> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>> Damian, a short note (and sorry about the lagged response):
>> 5. Debugger visualizer - let's not create yet another nuget package for >> it, instead just have it excluded from references and anyone who wants that >> can reference it later on.
>> 7. Ditto
>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>> Sure, should get some cycles to spend on it this week.
>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>> 2) Exposing json.net gives you a lot of power, actually. >>>> 3) We can avoid referencing NLog, but I am not going to introducing an >>>> abstraction for that. >>>> 5) We can do that, yes. >>>> 6) We don't need to do that, if you want to use TransactionScope, >>>> you'll do that, and we will integrate with that. >>>> 7) There isn't a way to add something just to MVC projects, and I want >>>> to avoid having bazziliion nuget packages. >>>> 8) Yes, that is because this can cause compilation issues, the others >>>> do not.
>>>> Damian, >>>> I will be honest and say that I actually pay very little attention to >>>> the way nuget works. >>>> Would you be able to send a pull request for those changes? >>>> Specifically, 1,5,7 would be great.
as a result of Ayende's blog post on NuGet, another thread regarding an FSharp dependency, and a brief email from Ayende (I did a 'reply to author' instead of to the group, my bad), I am going to make an attempt at doing fine-grained packages.
Let me spend some cycles on it and see if I arrive at something that is maintainable and satisfactory. It may be week or so...
On Monday, 12 March 2012 21:02:11 UTC, Itamar Syn-Hershko wrote:
> On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey wrote:
>> No problem Itamar, only getting around to it now.
>> I'm in two minds whether additional packages are worth it or not. The >> only thing is that if a reference is manually added and the developer >> updates the package through nuget, those references will have to be >> re-added manually. You ok with that?
> Yes
>> To specify explicit assembly references I have to use nuspec's <reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> >> element. I can codify this in the build script (default.ps1) or create a >> separate nuspec for the client. What is the team's preference? Personally, >> I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a >> concious decision to do it all in the build script?
> The build script is creating the folder structure to pack into nupkg and > then it can have list of DLLs we want to explicitly de-reference
>> I'll do the AsyncCtpLibrary dependency removal on the client in a >> separate pull request. Heard from a colleague that it was causing a >> conflict in VS11/.net4.5 too.
>> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>>> Damian, a short note (and sorry about the lagged response):
>>> 5. Debugger visualizer - let's not create yet another nuget package for >>> it, instead just have it excluded from references and anyone who wants that >>> can reference it later on.
>>> 7. Ditto
>>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>>> Sure, should get some cycles to spend on it this week.
>>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>>> 2) Exposing json.net gives you a lot of power, actually. >>>>> 3) We can avoid referencing NLog, but I am not going to introducing an >>>>> abstraction for that. >>>>> 5) We can do that, yes. >>>>> 6) We don't need to do that, if you want to use TransactionScope, >>>>> you'll do that, and we will integrate with that. >>>>> 7) There isn't a way to add something just to MVC projects, and I want >>>>> to avoid having bazziliion nuget packages. >>>>> 8) Yes, that is because this can cause compilation issues, the others >>>>> do not.
>>>>> Damian, >>>>> I will be honest and say that I actually pay very little attention to >>>>> the way nuget works. >>>>> Would you be able to send a pull request for those changes? >>>>> Specifically, 1,5,7 would be great.
On Monday, 12 March 2012 21:02:11 UTC, Itamar Syn-Hershko wrote:
> On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey <dhic...@gmail.com> wrote:
>> No problem Itamar, only getting around to it now.
>> I'm in two minds whether additional packages are worth it or not. The >> only thing is that if a reference is manually added and the developer >> updates the package through nuget, those references will have to be >> re-added manually. You ok with that?
> Yes
>> To specify explicit assembly references I have to use nuspec's <reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> >> element. I can codify this in the build script (default.ps1) or create a >> separate nuspec for the client. What is the team's preference? Personally, >> I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a >> concious decision to do it all in the build script?
> The build script is creating the folder structure to pack into nupkg and > then it can have list of DLLs we want to explicitly de-reference
>> I'll do the AsyncCtpLibrary dependency removal on the client in a >> separate pull request. Heard from a colleague that it was causing a >> conflict in VS11/.net4.5 too.
>> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>>> Damian, a short note (and sorry about the lagged response):
>>> 5. Debugger visualizer - let's not create yet another nuget package for >>> it, instead just have it excluded from references and anyone who wants that >>> can reference it later on.
>>> 7. Ditto
>>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>>> Sure, should get some cycles to spend on it this week.
>>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>>> 2) Exposing json.net gives you a lot of power, actually. >>>>> 3) We can avoid referencing NLog, but I am not going to introducing an >>>>> abstraction for that. >>>>> 5) We can do that, yes. >>>>> 6) We don't need to do that, if you want to use TransactionScope, >>>>> you'll do that, and we will integrate with that. >>>>> 7) There isn't a way to add something just to MVC projects, and I want >>>>> to avoid having bazziliion nuget packages. >>>>> 8) Yes, that is because this can cause compilation issues, the others >>>>> do not.
>>>>> Damian, >>>>> I will be honest and say that I actually pay very little attention to >>>>> the way nuget works. >>>>> Would you be able to send a pull request for those changes? >>>>> Specifically, 1,5,7 would be great.
On Wed, Mar 14, 2012 at 10:05 AM, Damian Hickey <dhic...@gmail.com> wrote: > Gent's,
> as a result of Ayende's blog post on NuGet, another thread regarding an > FSharp dependency, and a brief email from Ayende (I did a 'reply to author' > instead of to the group, my bad), I am going to make an attempt at doing > fine-grained packages.
> Let me spend some cycles on it and see if I arrive at something that is > maintainable and satisfactory. It may be week or so...
> Cheers
> Damian
> On Monday, 12 March 2012 21:02:11 UTC, Itamar Syn-Hershko wrote:
>> On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey wrote:
>>> No problem Itamar, only getting around to it now.
>>> I'm in two minds whether additional packages are worth it or not. The >>> only thing is that if a reference is manually added and the developer >>> updates the package through nuget, those references will have to be >>> re-added manually. You ok with that?
>> Yes
>>> To specify explicit assembly references I have to use nuspec's < >>> reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> >>> element. I can codify this in the build script (default.ps1) or create a >>> separate nuspec for the client. What is the team's preference? Personally, >>> I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a >>> concious decision to do it all in the build script?
>> The build script is creating the folder structure to pack into nupkg and >> then it can have list of DLLs we want to explicitly de-reference
>>> I'll do the AsyncCtpLibrary dependency removal on the client in a >>> separate pull request. Heard from a colleague that it was causing a >>> conflict in VS11/.net4.5 too.
>>> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>>>> Damian, a short note (and sorry about the lagged response):
>>>> 5. Debugger visualizer - let's not create yet another nuget package for >>>> it, instead just have it excluded from references and anyone who wants that >>>> can reference it later on.
>>>> 7. Ditto
>>>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>>>> Sure, should get some cycles to spend on it this week.
>>>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>>>> 2) Exposing json.net gives you a lot of power, actually. >>>>>> 3) We can avoid referencing NLog, but I am not going to introducing >>>>>> an abstraction for that. >>>>>> 5) We can do that, yes. >>>>>> 6) We don't need to do that, if you want to use TransactionScope, >>>>>> you'll do that, and we will integrate with that. >>>>>> 7) There isn't a way to add something just to MVC projects, and I >>>>>> want to avoid having bazziliion nuget packages. >>>>>> 8) Yes, that is because this can cause compilation issues, the others >>>>>> do not.
>>>>>> Damian, >>>>>> I will be honest and say that I actually pay very little attention to >>>>>> the way nuget works. >>>>>> Would you be able to send a pull request for those changes? >>>>>> Specifically, 1,5,7 would be great.
> On Monday, 12 March 2012 21:02:11 UTC, Itamar Syn-Hershko wrote:
>> On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey <dhic...@gmail.com>wrote:
>>> No problem Itamar, only getting around to it now.
>>> I'm in two minds whether additional packages are worth it or not. The >>> only thing is that if a reference is manually added and the developer >>> updates the package through nuget, those references will have to be >>> re-added manually. You ok with that?
>> Yes
>>> To specify explicit assembly references I have to use nuspec's < >>> reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> >>> element. I can codify this in the build script (default.ps1) or create a >>> separate nuspec for the client. What is the team's preference? Personally, >>> I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a >>> concious decision to do it all in the build script?
>> The build script is creating the folder structure to pack into nupkg and >> then it can have list of DLLs we want to explicitly de-reference
>>> I'll do the AsyncCtpLibrary dependency removal on the client in a >>> separate pull request. Heard from a colleague that it was causing a >>> conflict in VS11/.net4.5 too.
>>> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>>>> Damian, a short note (and sorry about the lagged response):
>>>> 5. Debugger visualizer - let's not create yet another nuget package for >>>> it, instead just have it excluded from references and anyone who wants that >>>> can reference it later on.
>>>> 7. Ditto
>>>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>>>> Sure, should get some cycles to spend on it this week.
>>>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>>>> 2) Exposing json.net gives you a lot of power, actually. >>>>>> 3) We can avoid referencing NLog, but I am not going to introducing >>>>>> an abstraction for that. >>>>>> 5) We can do that, yes. >>>>>> 6) We don't need to do that, if you want to use TransactionScope, >>>>>> you'll do that, and we will integrate with that. >>>>>> 7) There isn't a way to add something just to MVC projects, and I >>>>>> want to avoid having bazziliion nuget packages. >>>>>> 8) Yes, that is because this can cause compilation issues, the others >>>>>> do not.
>>>>>> Damian, >>>>>> I will be honest and say that I actually pay very little attention to >>>>>> the way nuget works. >>>>>> Would you be able to send a pull request for those changes? >>>>>> Specifically, 1,5,7 would be great.
On Wednesday, 14 March 2012 08:09:51 UTC, Fitzchak Yitzchaki wrote:
> Great! looking forward to see what you've got...
> On Wed, Mar 14, 2012 at 10:05 AM, Damian Hickey <dhic...@gmail.com> wrote:
>> Gent's,
>> as a result of Ayende's blog post on NuGet, another thread regarding an >> FSharp dependency, and a brief email from Ayende (I did a 'reply to author' >> instead of to the group, my bad), I am going to make an attempt at doing >> fine-grained packages.
>> Let me spend some cycles on it and see if I arrive at something that is >> maintainable and satisfactory. It may be week or so...
>> Cheers
>> Damian
>> On Monday, 12 March 2012 21:02:11 UTC, Itamar Syn-Hershko wrote:
>>> On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey wrote:
>>>> No problem Itamar, only getting around to it now.
>>>> I'm in two minds whether additional packages are worth it or not. The >>>> only thing is that if a reference is manually added and the developer >>>> updates the package through nuget, those references will have to be >>>> re-added manually. You ok with that?
>>> Yes
>>>> To specify explicit assembly references I have to use nuspec's < >>>> reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> >>>> element. I can codify this in the build script (default.ps1) or create a >>>> separate nuspec for the client. What is the team's preference? Personally, >>>> I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a >>>> concious decision to do it all in the build script?
>>> The build script is creating the folder structure to pack into nupkg and >>> then it can have list of DLLs we want to explicitly de-reference
>>>> I'll do the AsyncCtpLibrary dependency removal on the client in a >>>> separate pull request. Heard from a colleague that it was causing a >>>> conflict in VS11/.net4.5 too.
>>>> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>>>>> Damian, a short note (and sorry about the lagged response):
>>>>> 5. Debugger visualizer - let's not create yet another nuget package >>>>> for it, instead just have it excluded from references and anyone who wants >>>>> that can reference it later on.
>>>>> 7. Ditto
>>>>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>>>>> Sure, should get some cycles to spend on it this week.
>>>>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>>>>> 2) Exposing json.net gives you a lot of power, actually. >>>>>>> 3) We can avoid referencing NLog, but I am not going to introducing >>>>>>> an abstraction for that. >>>>>>> 5) We can do that, yes. >>>>>>> 6) We don't need to do that, if you want to use TransactionScope, >>>>>>> you'll do that, and we will integrate with that. >>>>>>> 7) There isn't a way to add something just to MVC projects, and I >>>>>>> want to avoid having bazziliion nuget packages. >>>>>>> 8) Yes, that is because this can cause compilation issues, the >>>>>>> others do not.
>>>>>>> Damian, >>>>>>> I will be honest and say that I actually pay very little attention >>>>>>> to the way nuget works. >>>>>>> Would you be able to send a pull request for those changes? >>>>>>> Specifically, 1,5,7 would be great.
>> On Monday, 12 March 2012 21:02:11 UTC, Itamar Syn-Hershko wrote:
>>> On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey <dhic...@gmail.com>wrote:
>>>> No problem Itamar, only getting around to it now.
>>>> I'm in two minds whether additional packages are worth it or not. The >>>> only thing is that if a reference is manually added and the developer >>>> updates the package through nuget, those references will have to be >>>> re-added manually. You ok with that?
>>> Yes
>>>> To specify explicit assembly references I have to use nuspec's < >>>> reference<http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Expl...>> >>>> element. I can codify this in the build script (default.ps1) or create a >>>> separate nuspec for the client. What is the team's preference? Personally, >>>> I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a >>>> concious decision to do it all in the build script?
>>> The build script is creating the folder structure to pack into nupkg and >>> then it can have list of DLLs we want to explicitly de-reference
>>>> I'll do the AsyncCtpLibrary dependency removal on the client in a >>>> separate pull request. Heard from a colleague that it was causing a >>>> conflict in VS11/.net4.5 too.
>>>> On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:
>>>>> Damian, a short note (and sorry about the lagged response):
>>>>> 5. Debugger visualizer - let's not create yet another nuget package >>>>> for it, instead just have it excluded from references and anyone who wants >>>>> that can reference it later on.
>>>>> 7. Ditto
>>>>> On Mon, Feb 27, 2012 at 11:15 PM, Damian Hickey wrote:
>>>>>> Sure, should get some cycles to spend on it this week.
>>>>>> On Monday, 27 February 2012 21:02:29 UTC, Ayende Rahien wrote:
>>>>>>> 1) We can avoid referencing the AsyncCtpLibrary, I guess. >>>>>>> 2) Exposing json.net gives you a lot of power, actually. >>>>>>> 3) We can avoid referencing NLog, but I am not going to introducing >>>>>>> an abstraction for that. >>>>>>> 5) We can do that, yes. >>>>>>> 6) We don't need to do that, if you want to use TransactionScope, >>>>>>> you'll do that, and we will integrate with that. >>>>>>> 7) There isn't a way to add something just to MVC projects, and I >>>>>>> want to avoid having bazziliion nuget packages. >>>>>>> 8) Yes, that is because this can cause compilation issues, the >>>>>>> others do not.
>>>>>>> Damian, >>>>>>> I will be honest and say that I actually pay very little attention >>>>>>> to the way nuget works. >>>>>>> Would you be able to send a pull request for those changes? >>>>>>> Specifically, 1,5,7 would be great.
