Getting to DynamicProxy 2.0

[Jonathon Rossi]

I just created a roadmap page on confluence with the open issues from donjon for DynamicProxy:
http://using.castleproject.org/display/Tools/DynamicProxy

I looks like some of the open issues aren't issues anymore, so we need to close a few off. I'd also assume we don't want to make changes to DynamicProxy 1.x anymore.

What does everyone think needs to be fixed/added to DynamicProxy 2.x to be able to get to a releasable 2.0?

--
Jonathon Rossi

[hammett]

AFAIC DP2 was released on the last RC. So you're looking into 2.1 or 2.0.1

--
Cheers,
hammett
http://hammett.castleproject.org/

[Jonathon Rossi]

I thought that was just an RC of 2.0. It is hard to tell what version all the different projects were at with RC3.

--
Jonathon Rossi

[hammett]

Yep, that's what we are trying to fix :-)

[Jonathon Rossi]

Since you can't actually download a final/GA/RTM of DP 2.0, should we call it 2.0? Or would you prefer to jump to 2.1?

--
Jonathon Rossi

[hammett]

I'd vote for 2.1
2.0 is very stable.

[Jonathon Rossi]

2.1 sounds good, it avoids confusion.

So what do we want in 2.1 and what should be deferred to 2.2?

--
Jonathon Rossi

[Krzysztof Koźmic]

How about creating UserVoice.com page for DP and gather ideas there. I think it would work better than discussion group, and more people would use it.
Also +1 on calling new version v2.1

Also, since AFAIR only IBatis facility still uses DP1 in whole Castle project, how about calling the dll DynamicProxy.dll instead of DynamicProxy2.dll
Krzysztof

Jonathon Rossi pisze:

[Jonathon Rossi]

UserVoice looks interesting. The only problem is that it does duplicate what we store in donjon and since anyone can create issues in donjon it partially voids the need for another ideas tracking system. I think donjon just needs to be fixed up so that it emails the mailing list for new and changed issues like JIRA used to do.

+1 for dropping the 2 in the assembly name as we move forward.

I don't know if the current source repository layout is going to work very well, because tags and branches really need to be at the project level not at the repository root, we also need to move the documentation into the project. Hammett, do you have any plans for changing the repository layout?

For example:
/Tools/Castle.DynamicProxy2/trunk
  /src
  /doc
  /lib

--
Jonathon Rossi

[Krzysztof Koźmic]

About UserVoice, my idea was not to duplicate every issue there.
Rather do what StackOverflow, or AnkhSVN teams did. They use UserVoice as a place where users can suggest and vote for and comment on new features. IIRC it does not even require you to create an account to vote to suggest a feature. It's interface is also very readable. You can instantly see what features are most popular or requested. AFAIK there's no such functionality in Donjon (at least yet). So, the way I see it, Donjon would stay as issue tracker, and UserVoice would be low friction tool for people to gether feedback and ideas.

Krzysztof

Jonathon Rossi pisze:

[Gauthier Segay]

I'm not direct DynamicProxy, only using it remotely through MK
interceptors and NH proxies.

However one thing I find lacking is the ability to proxy a type for a
specific interface when the type has an explicit interface
implementation (aka private members).

I don't know if it's a concern to anyone but me.

On Nov 2, 8:17 am, Krzysztof Koźmic <krzysztof.koz...@gmail.com>
wrote:

> How about creating UserVoice.com page for DP and gather ideas there. I
> think it would work better than discussion group, and more people would
> use it.
> Also +1 on calling new version v2.1
>
> Also, since AFAIR only IBatis facility still uses DP1 in whole Castle
> project, how about calling the dll DynamicProxy.dll instead of
> DynamicProxy2.dll
> Krzysztof
>
> Jonathon Rossi pisze:
>
> > 2.1 sounds good, it avoids confusion.
>
> > So what do we want in 2.1 and what should be deferred to 2.2?
>

> > On Sun, Nov 2, 2008 at 2:02 PM, hammett <hamm...@gmail.com
> > <mailto:hamm...@gmail.com>> wrote:
>
> >     I'd vote for 2.1
> >     2.0 is very stable.
>

> >     On Sat, Nov 1, 2008 at 8:31 PM, Jonathon Rossi <j...@jonorossi.com

> >     <mailto:j...@jonorossi.com>> wrote:
> >     > Since you can't actually download a final/GA/RTM of DP 2.0,
> >     should we call
> >     > it 2.0? Or would you prefer to jump to 2.1?
>

> >     > On Sun, Nov 2, 2008 at 1:28 PM, hammett <hamm...@gmail.com

> >     <mailto:hamm...@gmail.com>> wrote:
>
> >     >> Yep, that's what we are trying to fix :-)
>
> >     >> On Sat, Nov 1, 2008 at 8:25 PM, Jonathon Rossi

> >     <j...@jonorossi.com <mailto:j...@jonorossi.com>> wrote:
> >     >> > I thought that was just an RC of 2.0. It is hard to tell what
> >     version
> >     >> > all
> >     >> > the different projects were at with RC3.
>

> >     >> > On Sun, Nov 2, 2008 at 1:22 PM, hammett <hamm...@gmail.com

> >     <mailto:hamm...@gmail.com>> wrote:
>
> >     >> >> AFAIC DP2 was released on the last RC. So you're looking
> >     into 2.1 or
> >     >> >> 2.0.1
>
> >     >> >> On Sat, Nov 1, 2008 at 8:09 PM, Jonathon Rossi

> >     <j...@jonorossi.com <mailto:j...@jonorossi.com>>

[hammett]

Patch?

2008/11/2 Gauthier Segay <gauthie...@gmail.com>:

[hammett]

Before doing so we'd need a patch that update the nant files.

2008/11/2 Jonathon Rossi <jo...@jonorossi.com>:

[Jonathon Rossi]

Before doing so we'd need a patch that update the nant files.

Were you referring to the assembly name change or the repository layout change?

If the repository layout change, do you want a patch to separate all the nant scripts, so that they can be run separately?

--
Jonathon Rossi

[Fabian Schmied]

> What does everyone think needs to be fixed/added to DynamicProxy 2.x to be
> able to get to a releasable 2.0?

First, we have some workarounds for problems that existed in .NET 2.0.
Those were mostly fixed in .NET 2.0 SP1.
Second, Hammett removed a feature (Managed C++/F#/Spec# support
through custom modifiers) due to a bug introduced by .NET 2.0 SP2
(.NET 3.5 SP1). The bug is fixed in a hotfix, which will be
distributed via Windows Update as soon as .NET 2.0 SP2 goes to Windows
Update.

For both issues we have to decide how we want to deal with them in the
next release.
- Can we add .NET 2.0 SP1 as a prerequisite? If yes, we can remove a
few workarounds (and also improve performance a bit).
- Do we have to support the broken .NET 2.0 SP2 or can we demand that
2.0 SP2 users also install the hotfix? If the latter, we can re-add
custom modifier support.

There is also one issue that hasn't been implemented yet:
IInterceptorSelector, which allows for more efficient code generation.
I think this should be in the next release.

And lastly, there is one issue that has led to problems in the past:
property overrides. Those aren't really needed (it would be sufficient
to override the get/set methods), and they sometimes confuse tools
that perform reflection on the generated types

Fabian

[Fabian Schmied]

> I just created a roadmap page on confluence with the open issues from donjon
> for DynamicProxy:
> http://using.castleproject.org/display/Tools/DynamicProxy
>
> I looks like some of the open issues aren't issues anymore, so we need to
> close a few off. I'd also assume we don't want to make changes to
> DynamicProxy 1.x anymore.

I think the following issues are not relevant any more:
- DYNPROXY-ISSUE-30: Proxies are not serializable (I remember writing
serialization tests, so at least _some_ proxies should be
serializable)
- DYNPROXY-ISSUE-36: Support for mixins

The following is a Visual Studio (2005 and 2008, I think) bug; we
_could_ work around it by having DynamicProxy create a new assembly
every 50 proxy types or so, but that would have strong side-effects on
code expecting DP to generate only one assembly:
- DYNPROXY-ISSUE-72: Poor performance while running in Debug Mode
inside Visual Studio 2005

The following should be tested, I'm not sure about them; they
definitely sound like blockers:
- DYNPROXY-ISSUE-32: Must support proxying internal types when
InternalsVisibleTo is used
- DYNPROXY-ISSUE-49: Type exception when generic type implementation
has a constraint that the interface doesn't have
- DYNPROXY-ISSUE-74: CreateInterfaceProxyWithoutTarget fails with
interface containing member with 'out IntPtr'
(Hasn't Ayende fixed this one?)
- DYNPROXY-ISSUE-77: DYNPROXY-ISSUE-58 is open again in Build 933
(DP2: Inherited interface seems not to work)

Fabian

[Jonathon Rossi]

Thanks Fabian for summarising outstanding issues.

I guess the first decision is to decide on the .NET prerequisite. Since .NET 2.0 SP1 was release a year ago, I'm sure most people would have it installed. I'd don't see requiring SP1 a problem, however requiring the hotfix for SP2 might be a little more problematic. Once the fix has been pushed via Windows Updates I don't see a problem in requiring it. What is everyone's opinion?

The InternalsVisibleTo issue also looks like it is fixed.

--
Jonathon Rossi

[Julian Birch]

Could I suggest that in either case, where the change is made, a check is put in that throws an exception that explains that, for instance, you need SP1 and haven't got it?  It'll save some developers a lot of time.

2008/11/3 Jonathon Rossi <jo...@jonorossi.com>

[Ayende Rahien]

Check the rhino mocks test for this, it checks the version and ignore the test if this is in the faulty version

[hammett]

On Mon, Nov 3, 2008 at 2:11 AM, Fabian Schmied <fabian....@gmail.com> wrote:
> For both issues we have to decide how we want to deal with them in the
> next release.
> - Can we add .NET 2.0 SP1 as a prerequisite? If yes, we can remove a
> few workarounds (and also improve performance a bit).
> - Do we have to support the broken .NET 2.0 SP2 or can we demand that
> 2.0 SP2 users also install the hotfix? If the latter, we can re-add
> custom modifier support.

Due to reach that DP gets by dependent libraries, I'd suggest that it
should _not_ be a prerequisite to have a specific SP installed.

> And lastly, there is one issue that has led to problems in the past:
> property overrides. Those aren't really needed (it would be sufficient
> to override the get/set methods), and they sometimes confuse tools
> that perform reflection on the generated types

I thought we had expressed that we are OK with that change. I'd
suggest postponing it, though.

[hammett]

On Sun, Nov 2, 2008 at 1:57 PM, Jonathon Rossi <jo...@jonorossi.com> wrote:
> Were you referring to the assembly name change or the repository layout
> change?

Layout

> If the repository layout change, do you want a patch to separate all the
> nant scripts, so that they can be run separately?

I'm not sure. Whatever keeps the building working.

[Gauthier Segay]

Well I need to learn the A B C of IL generation, which surely would
prove usefull, thanks for the invitation :)

On Nov 2, 7:18 pm, hammett <hamm...@gmail.com> wrote:
> Patch?
>
> 2008/11/2 Gauthier Segay <gauthier.se...@gmail.com>:

[Krzysztof Koźmic]

IIRC you don't.

Actually as far as I can remember this change would require you to overload single method, that collects methods to proxy.
You'll only need some reflection, and existing implementation will do the hard work. But I may be wrong. Don't have the code in front of me right now.

Krzysztof

Gauthier Segay pisze:

[Gauthier Segay]

Thanks for the hint, I will have a spin at it this we

On Nov 5, 7:48 am, Krzysztof Koźmic <krzysztof.koz...@gmail.com>