What do you mean by "Core as it stands today will have to be split and
part of it merged with DP, while majority would move to new
Windsor." ?
Also, by projects I mean VS projects not Castle projects, so having
many VS projects that get ilmerged together for shipping, I don't see
that as a disadvantage/maintenance overhead.

Cheers
John

On Feb 9, 6:02 pm, Krzysztof Koźmic <[email protected]>
wrote:
> It's not really that.
> We need a sharper tool than ILMerge, because Core as it stands today
> will have to be split and part of it merged with DP, while majority
> would move to new Windsor.
>
> Plus we don't really need to maintain that many projects which proved to
> be not such a great idea.
>
> Krzysztof
>
> On 2010-02-09 00:03, John Simons wrote:
>
> > Sorry if this has been asked before, but how about using ilmerge to
> > merge Core + DP into one single file?
> > If the benefit of merging the projects is so that we end up with only
> > one file, then we may as well use ilmerge and keep the projects
> > separate.
>
> > Cheers
> > John
>
> > On Feb 9, 8:56 am, Krzysztof Koźmic<[email protected]>
> > wrote:
>
> >> On 2010-02-08 22:55, Jonathon Rossi wrote:>  I don't know, just guessing. 
> >> Maybe it is being underneath their own
>
> >>> Windsor like abstraction, no idea. Maybe no one does this.
>
> >>> But we do want to let people know that you don't need the MK.dll anymore.
>
> >> Yeah, definitely we don't want anyone to think it just disappeared into
> >> the thin air,
>
> >>> 2010/2/9 Krzysztof Koďż˝mic<[email protected]
> >>> <mailto:[email protected]>>
>
> >>>      On 2010-02-08 22:52, Jonathon Rossi wrote:
>
> >>>>      2010/2/9 Krzysztof Koďż˝mic<[email protected]
> >>>>      <mailto:[email protected]>>
>
> >>>>          Yes, I don't want to change any namespaces.
>
> >>>>          And I agree that making it Castle.Core.dll is probably the
> >>>>          most sensible idea. The Logging and few other things do have
> >>>>          to live in that assembly (rest can be safely moved to newly
> >>>>          merged Castle.Windsor.dll incl. current Castle.MicroKernel)
> >>>>          so it's more logical to have things like logging adapters in
> >>>>          Foo.Core than in Foo.DynamicProxy...
>
> >>>>          We just will have to take extra care to make it extremely
> >>>>          obvious that DP did not disappear from the face of the earth,
> >>>>          and that its safe and sound in the new assembly.
>
> >>>>      Definitely. The same for MicroKernel because there is very likely
> >>>>      people out there that use MK and not Windsor.
>
> >>>      There are?
>
> >>>>          Krzysztof
>
> >>>>          On 2010-02-08 22:42, Jonathon Rossi wrote:
>
> >>>>>          We should keep the number until v3 to avoid confusion and
> >>>>>          avoid breaking things.
>
> >>>>>          I was under the assumption that we would merge DP into Core
> >>>>>          for v3, so there is no issue with having a number in the
> >>>>>          filename post-v2.
>
> >>>>>          My understanding was that we wanted to get rid of the DP DLL
> >>>>>          because very few people using Castle Core wouldn't already
> >>>>>          be using DP. I assume we plan to keep the current
> >>>>>          Castle.DynamicProxy namespace when it moves inside
> >>>>>          Castle.Core.dll, rather than making it
> >>>>>          Castle.Core.DynamicProxy or something. Which means it
> >>>>>          becomes more System.Core like.
>
> >>>>>          When the 2 merge, I would vote for versioning Castle.Core at
> >>>>>          3.0.
>
> >>>>>          I'm -1 for renaming Castle.Core.dll. I think it would cause
> >>>>>          more confusion by changing everything other than just
> >>>>>          dropping DP inside Castle.Core.dll. A screenshot of
> >>>>>          reflector with Castle.Core.dll open on the DP home page
> >>>>>          would probably make things really obvious to anyone who visits.
>
> >>>>>          2010/2/9 Krzysztof Koďż˝mic<[email protected]
> >>>>>          <mailto:[email protected]>>
>
> >>>>>              Perhaps we should just ditch the 2 instead?
>
> >>>>>              Trunk is going to become v3 anyway so I see no point in
> >>>>>              having a number in the assembly version.
>
> >>>>>              Another issue altogether is that if we would merge Core
> >>>>>              (parts) + DynamicProxy + (perhaps) DictionaryAdapter
> >>>>>              maybe a new assembly name altogether would make sense,
> >>>>>              like making it Castle.Core.dll, although we would have
> >>>>>              to have a very clear message somewhere to route people
> >>>>>              looking for DP or DA to the new Core... or perhaps just
> >>>>>              Castle.dll...
> >>>>>              I don't know, I'm just throwing ideas out as they run
> >>>>>              through my head right now.
>
> >>>>>              Krzysztof
>
> >>>>>              On 2010-02-08 11:05, Jonathon Rossi wrote:
>
> >>>>>>              The Visual Studio project outputs
> >>>>>>              Castle.DynamicProxy.dll while nant outputs
> >>>>>>              Castle.DynamicProxy2.dll.
>
> >>>>>>              I think the only reason the VS project doesn't have the
> >>>>>>              2 is that its namespace doesn't have a 2 and it was
> >>>>>>              like that since the beginning so we could run 1 and 2
> >>>>>>              side-by-side. If no one objects, I will fix the VS
> >>>>>>              project to always output with a 2 which is a
> >>>>>>              non-breaking change.
>
> >>>>>>              On Mon, Feb 8, 2010 at 7:27 PM, Julian Birch
> >>>>>>              <[email protected]
> >>>>>>              <mailto:[email protected]>>  wrote:
>
> >>>>>>                  Hi, the Castle Windsor csproj references a
> >>>>>>                  "Castle.DynamicProxy2.dll".  The Castle DP project
> >>>>>>                  compiles to Castle.DynamicProxy.dll.  Now, I
> >>>>>>                  understand that once this might have made sense,
> >>>>>>                  but isn't it just unnecessary friction these days?
> >>>>>>                  It seems that the only way to determine that this
> >>>>>>                  DLL is related to the project is to read the XML on
> >>>>>>                  one side and hit reflection on the other.
> >>>>>>                  If there isn't a good reason for it, could someone
> >>>>>>                  fix it please?
> >>>>>>                  Julian.
> >>>>>>                  --
> >>>>>>                  You received this message because you are
> >>>>>>                  subscribed to the Google Groups "Castle Project
> >>>>>>                  Development List" group.
> >>>>>>                  To post to this group, send email to
> >>>>>>                  [email protected]
> >>>>>>                  <mailto:[email protected]>.
> >>>>>>                  To unsubscribe from this group, send email to
> >>>>>>                  [email protected]
> >>>>>>                  
> >>>>>> <mailto:castle-project-devel%[email protected]>.
> >>>>>>                  For more options, visit this group at
> >>>>>>                
> >>>>>> http://groups.google.com/group/castle-project-devel?hl=en.
>
> >>>>>>              --
> >>>>>>              Jono
> >>>>>>              --
> >>>>>>              You received this message because you are subscribed to
> >>>>>>              the Google Groups "Castle Project Development List" group.
> >>>>>>              To post to this group, send email to
> >>>>>>              [email protected]
> >>>>>>              <mailto:[email protected]>.
> >>>>>>              To unsubscribe from this group, send email to
> >>>>>>              [email protected]
> >>>>>>              
> >>>>>> <mailto:[email protected]>.
> >>>>>>              For more options, visit this group at
> >>>>>>            http://groups.google.com/group/castle-project-devel?hl=en.
>
> >>>>>              --
> >>>>>              You received this message because you are subscribed to
> >>>>>              the Google Groups "Castle Project Development List" group.
> >>>>>              To post to this group, send email to
> >>>>>              [email protected]
> >>>>>              <mailto:[email protected]>.
> >>>>>              To unsubscribe from this group, send email to
> >>>>>              [email protected]
> >>>>>              
> >>>>> <mailto:castle-project-devel%[email protected]>.
> >>>>>              For more options, visit this group at
> >>>>>            http://groups.google.com/group/castle-project-devel?hl=en.
>
> >>>>>          --
> >>>>>          Jono
> >>>>>          --
> >>>>>          You received this message because you are subscribed to the
> >>>>>          Google Groups "Castle Project Development List" group.
> >>>>>          To post to this group, send email to
> >>>>>          [email protected]
> >>>>>          <mailto:[email protected]>.
> >>>>>          To unsubscribe from this group, send email to
> >>>>>          [email protected]
> >>>>>          <mailto:[email protected]>.
> >>>>>          For more options, visit this group at
> >>>>>        http://groups.google.com/group/castle-project-devel?hl=en.
>
> >>>>          --
> >>>>          You received this message because you are subscribed to the
> >>>>          Google Groups "Castle Project Development List" group.
> >>>>          To post to this group, send email to
> >>>>          [email protected]
> >>>>          <mailto:[email protected]>.
> >>>>          To unsubscribe from this group, send
>
> ...
>
> read more >>

-- 
You received this message because you are subscribed to the Google Groups 
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/castle-project-devel?hl=en.

Reply via email to