RE: Generic Interface Question (.net 4.0)

[James Chapman-Smith]

Hi Wolfgang,

 

The simplest approach, which also works in 3.5, is to create an IPersistor
interface that IPersistor inherits from. Then you can assign any
IPersistor to a variable of IPersistor.

 

In 4.0 though, you can now use co-variance or contravariance (not both) when
designing your interface. So if you have only "in" parameters of type T you
can define the IPersistor interface as IPersistor which would allow
you to assign IPersistor to IPersistor provided that C inherits from
B. If you only have "out" parameters ie return types of T then you can
define IPersistor as IPersistor which would allow you to assign
IPersistor to IPersistor provided that B inherits from A.

 

It's this latter case that would allow you to assign persistors to
IPersistor, but I suspect that the interface is not an "out"
interface. If that's correct you need to stick to the 3.5 functionality.

 

Cheers.

 

James.

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Wolfgang Von Steinberg
Sent: Sunday, 7 November 2010 16:01
To: ozdotnet@ozdotnet.com
Subject: Generic Interface Question (.net 4.0)

 

Hello

 

I am using .net 4.0

 

I have :

 

IPersistor

 

and 

 

class CausePersistor implementing IPersistor

class PersonPersistor implementing IPersistor

 

now, how can I have something like :

 

IPersistor persistor; where I could assign an object that implements either
IPersistor , IPersistor ?

 

In other words what is the abstraction to be used for IPersistor ?

 

I already tried 

 

 IPersistor persistor = new CausePersistor(); but this doesn't
compile.

 

Thank you

 

WVS

Generic Interface Question (.net 4.0)

[Wolfgang Von Steinberg]

Hello

I am using .net 4.0

I have :

IPersistor

and

class CausePersistor implementing IPersistor
class PersonPersistor implementing IPersistor

now, how can I have something like :

IPersistor persistor; where I could assign an object that implements
either IPersistor , IPersistor ?

In other words what is the abstraction to be used for IPersistor ?

I already tried

 IPersistor persistor = new CausePersistor(); but this doesn't
compile.

Thank you

WVS

Async CTP

[.net noobie]

http://msdn.microsoft.com/en-us/vstudio/async.aspx

http://channel9.msdn.com/Blogs/Charles/Anders-Hejlsberg-Introducing-Async

http://channel9.msdn.com/Tags/async+ctp

has anyone checked this out?

looks pretty cool, but does not play well with resharper yet :(
you need to disable resharper to get VS to show the new stuff correctly

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Stovell]

I wonder if that's a product of TFS architecture - generally most companies 
have one TFS server, with many team projects and project collections. There are 
licensing/admin costs associated with doing it differently.

With a DVCS you might find you end up with lots of smaller repositories - one 
for the VS core, individual repositories for different VS features, different 
repositories for branches, different repositories for System.Web.* vs. WPF vs. 
WCF, etc.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Kean
Sent: Saturday, 6 November 2010 4:32 AM
To: ozDotNet
Subject: RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

How big are the databases that you are using? I'd imagine that there would be 
huge savings in using a DVCS for small self-contained repositories, however, 
there would be a given size where using one would no longer be an advantage. 
For example, I can't imagine a DVCS working at Microsoft; a full enlistment in 
one branch in DevDiv is around 300 GB (times that by 100s of branches) - having 
everyone pull that down and all the history along with it, would not be fun.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Mark Ryall
Sent: Friday, November 05, 2010 11:19 AM
To: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

I'm using svn again now after using git and hg for a few years (tfs was in 
there too - i don't want to talk about that).  I always liked svn and found it 
adequate but don't anymore.

There's nothing a DVCS provides that you can't live without - just as 64Kb of 
RAM was once perfectly adequate.

There are just a whole lot of things with DVCS that suddenly become easier or 
possible.  While you might not have considered these things earlier (because 
you couldn't), you really miss them when you can't.
They are insanely fast - especially git.  You will notice how fast they are 
every time you need to do a commit.  Insanely fast encourages more frequent 
commits.  The fact that after a clone, you end up with the entire history of a 
project locally (including every branch) in far less time than svn would take 
to check out a single code line (due to all the thousands of tiny control files 
it needs to create in every directory) is the winner for me.

Hosting is free or really cheap (bitbucket/github/launchpad).

For an open source project, fork/send pull request is a much lower barrier to 
entry for collaboration than checkout/email patch file.  If you accept a pull 
request, that person's commit becomes part of your codebase as them without you 
needing to provide direct commit access (as opposed to their changes being 
committed from a patch by you).

I prefer to avoid branching where possible but they make branching effortlessly 
easy.  Merging with git/hg is trivial and is properly tracked unlike with svn.  
Merging is always awful but git in particular seems to have some preternatural 
ability to help you get it right.

DVCS won't make you taller, more muscular or attractive though (i've tried - it 
really doesn't work) so use your best judgement.

On Wednesday, 3 November 2010 at 6:43 PM, silky wrote:
On Thu, Nov 4, 2010 at 12:37 PM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
argumentative? silky? GTFO!

:)


Most of my experience with DVCS has been with
mercurial (hg) which I've used for about the last 2 years for my personal
stuff. Before that I used SVN. I think the difference (from my point of
view) is that hg works well in a super-set of configurations to TFS/SVN. If
you were a solo developer with TFS installed locally then hg probably
wouldn't be that much better (it certainly handles branching, merging and
backing up more cleanly than TFS/SVN). But most people don't work that  way
- the server is remote. If you want to look at the 'history' for a file or
do a diff it's a network operation. Checking out is a network operation (at
least for TFS it is...not sur e about SVN). In the case of TFS 2008 when the
server was off-line work ground to a halt. With hg sometimes there _is_ no
central server. I've had good experiences collaborating with other devs
using hg with no central server set up, just sending patches back and forth
for synchronization. You can set up your development processes such that
your DVCS is fairly centralized (like things would be with TFS/SVN) - devs
commit and push/pull often. Then you just get the perf wins of local disk
I/O vs. network I/O and better merging capabilities.

Yeah, this is what I thought. And I can't help but feel this is
totally overrated. I mean, I don't know a single person who would say
using SVN is slow. It's never slowed me down at all (perhaps I'm just
slow in general?). Checkout takes a while, sure, but you don't do that
every day. Infact, you normally only do it a few times, perhaps when
creating a branch or something.

O kay, so you are telling me that perhaps git/hg i

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Sun, Nov 7, 2010 at 10:23 AM, Joseph Cooney  wrote:
> Yeah, tfs integration is very good. There is a dvcs that has integrated bug,
> work item tracking and wiki (called fossil) from the makers of sqlite. I
> haven't used it, but it will be interesting to see how long tfs retains this
> advantage.

You've been able to do this since forever with svn+trac, and it looks
like there is a plugin for mercurial as well:
http://trac.edgewall.org/wiki/TracMercurial


> Joseph
> --
>
> w: http://jcooney.net
> t: @josephcooney

-- 
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Joseph Cooney]

Yeah, tfs integration is very good. There is a dvcs that has integrated bug, 
work item tracking and wiki (called fossil) from the makers of sqlite. I 
haven't used it, but it will be interesting to see how long tfs retains this 
advantage.

On 06/11/2010, at 6:01 PM, David Kean  wrote:

> I’d be surprised if it’s as large as DevDiv – it’s not the Framework that is 
> huge, it’s the largest product (in code size) that we make; VS. ;)
> 
>  
> 
> I suspect a GB wouldn’t be bad, I easily pull down over 10 GB in my 
> enlistments from TFS, so assumingly a DVCS could easily handle that, only 
> with faster commits  and history.
> 
>  
> 
> However, if you want the integration – TFS is definitely the way to go 
> (however, I am biased J).
> 
>  
> 
> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
> Behalf Of Joseph Cooney
> Sent: Friday, November 05, 2010 8:30 PM
> To: ozDotNet
> Cc: ozDotNet
> Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?
> 
>  
> 
> There is a mercurial vide from 2006 where they say some folks have gb-sized 
> source trees. Mono use Git - which would be roughly the same size as a devdiv 
> branch (an assumption based on the fact that they deliver equivalent 
> functionality using the same language, unless you folk store VMs or something 
> else big in your source tree that they don't). Linux kernel uses git, but 
> they are well under a gb, as is Mozilla with hg.
> 
> 
> On 06/11/2010, at 4:32 AM, David Kean  wrote:
> 
> How big are the databases that you are using? I’d imagine that there would be 
> huge savings in using a DVCS for small self-contained repositories, however, 
> there would be a given size where using one would no longer be an advantage. 
> For example, I can’t imagine a DVCS working at Microsoft; a full enlistment 
> in one branch in DevDiv is around 300 GB (times that by 100s of branches) – 
> having everyone pull that down and all the history along with it, would not 
> be fun.
> 
>  
> 
> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
> Behalf Of Mark Ryall
> Sent: Friday, November 05, 2010 11:19 AM
> To: ozDotNet
> Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?
> 
>  
> 
> I'm using svn again now after using git and hg for a few years (tfs was in 
> there too - i don't want to talk about that).  I always liked svn and found 
> it adequate but don't anymore.
> 
>  
> 
> There's nothing a DVCS provides that you can't live without - just as 64Kb of 
> RAM was once perfectly adequate.
> 
>  
> 
> There are just a whole lot of things with DVCS that suddenly become easier or 
> possible.  While you might not have considered these things earlier (because 
> you couldn't), you really miss them when you can't.
> 
> They are insanely fast - especially git.  You will notice how fast they are 
> every time you need to do a commit.  Insanely fast encourages more frequent 
> commits.  The fact that after a clone, you end up with the entire history of 
> a project locally (including every branch) in far less time than svn would 
> take to check out a single code line (due to all the thousands of tiny 
> control files it needs to create in every directory) is the winner for me.
> 
>  
> 
> Hosting is free or really cheap (bitbucket/github/launchpad).
> 
>  
> 
> For an open source project, fork/send pull request is a much lower barrier to 
> entry for collaboration than checkout/email patch file.  If you accept a pull 
> request, that person's commit becomes part of your codebase as them without 
> you needing to provide direct commit access (as opposed to their changes 
> being committed from a patch by you).
> 
> I prefer to avoid branching where possible but they make branching 
> effortlessly easy.  Merging with git/hg is trivial and is properly tracked 
> unlike with svn.  Merging is always awful but git in particular seems to have 
> some preternatural ability to help you get it right.
> 
> DVCS won't make you taller, more muscular or attractive though (i've tried - 
> it really doesn't work) so use your best judgement.
> 
> On Wednesday, 3 November 2010 at 6:43 PM, silky wrote:
> 
> On Thu, Nov 4, 2010 at 12:37 PM, Joseph Cooney  
> wrote:
> 
> 
> 
> argumentative? silky? GTFO!
> 
> 
> :)
> 
> 
> 
> 
> 
> Most of my experience with DVCS has been with
> mercurial (hg) which I've used for about the last 2 years for my personal
> stuff. Before that I used SVN. I think the difference (from my point of
> view) is that hg works well in a super-set of configurations to TFS/SVN. If
> you were a solo developer with TFS installed locally then hg probably
> wouldn't be that much better (it certainly handles branching, merging and
> backing up more cleanly than TFS/SVN). But most people don't work that  way
> - the server is remote. If you want to look at the 'history' for a file or
> do a diff it's a network operation. Checking out is a network operation (at
> least for TFS i

RE: Plugin architecture for asp.net

[David Kean]

Yep, we produce a version for 3.5 (http://mef.codeplex.com/releases/view/40606)


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Winston Pang
Sent: Saturday, November 06, 2010 6:25 AM
To: ozDotNet
Subject: Re: Plugin architecture for asp.net

I think you can download it as standalone assembly as well, go to the MEF 
codeplex page.

Sent from my iPhone

On 06/11/2010, at 11:56 PM, "Anthony" 
mailto:asale...@tpg.com.au>> wrote:
Bugger..i think it is only for dotnet 4 framework

From: ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Anthony
Sent: Saturday, 6 November 2010 10:23 PM
To: 'ozDotNet'
Subject: RE: Plugin architecture for asp.net

Thanks Craig..exactly what i was looking for ☺

From: ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Craig van Nieuwkerk
Sent: Saturday, 6 November 2010 8:39 AM
To: ozDotNet
Subject: Re: Plugin architecture for asp.net

I would check out MEF. I don't have much experiece with it but think it is more 
of a plugin framework than Unity which is used for Dependency Injection.

Craig
On Fri, Nov 5, 2010 at 11:54 PM, Anthony 
mailto:asale...@tpg.com.au>> wrote:

Is Microsoft Unity Application block a plugin architecture or should i use 
another method to add a plugin feature to my asp.net app?

Is your website being 
IntelliXperienced?  | 
www.yougoingmyway.com ?
regards
Anthony (*12QWERNB*)

Is your website being IntelliXperienced?

Re: Plugin architecture for asp.net

[Winston Pang]

I think you can download it as standalone assembly as well, go to the MEF 
codeplex page.

Sent from my iPhone

On 06/11/2010, at 11:56 PM, "Anthony"  wrote:

> Bugger..i think it is only for dotnet 4 framework
> 
>  
> 
> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
> Behalf Of Anthony
> Sent: Saturday, 6 November 2010 10:23 PM
> To: 'ozDotNet'
> Subject: RE: Plugin architecture for asp.net
> 
>  
> 
> Thanks Craig..exactly what i was looking for J
> 
>  
> 
> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
> Behalf Of Craig van Nieuwkerk
> Sent: Saturday, 6 November 2010 8:39 AM
> To: ozDotNet
> Subject: Re: Plugin architecture for asp.net
> 
>  
> 
> I would check out MEF. I don't have much experiece with it but think it is 
> more of a plugin framework than Unity which is used for Dependency Injection.
> 
>  
> 
> Craig
> 
> On Fri, Nov 5, 2010 at 11:54 PM, Anthony  wrote:
> 
> Is Microsoft Unity Application block a plugin architecture or should i use 
> another method to add a plugin feature to my asp.net app?
> 
> Is your website being IntelliXperienced?  | www.yougoingmyway.com ?
> regards
> Anthony (*12QWERNB*)
> 
> Is your website being IntelliXperienced?
> 
>  
> 
>  

RE: Plugin architecture for asp.net

[Anthony]

Bugger..i think it is only for dotnet 4 framework

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Anthony
Sent: Saturday, 6 November 2010 10:23 PM
To: 'ozDotNet'
Subject: RE: Plugin architecture for asp.net

 

Thanks Craig..exactly what i was looking for J

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Craig van Nieuwkerk
Sent: Saturday, 6 November 2010 8:39 AM
To: ozDotNet
Subject: Re: Plugin architecture for asp.net

 

I would check out MEF. I don't have much experiece with it but think it is
more of a plugin framework than Unity which is used for Dependency
Injection.

 

Craig

On Fri, Nov 5, 2010 at 11:54 PM, Anthony  wrote:

Is Microsoft Unity Application block a plugin architecture or should i use
another method to add a plugin feature to my asp.net app?

  Is your website being
IntelliXperienced?  | www.yougoingmyway.com ?
regards
Anthony (*12QWERNB*)

Is your website being IntelliXperienced?

 

 

RE: Plugin architecture for asp.net

[Anthony]

Thanks Craig..exactly what i was looking for J

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Craig van Nieuwkerk
Sent: Saturday, 6 November 2010 8:39 AM
To: ozDotNet
Subject: Re: Plugin architecture for asp.net

 

I would check out MEF. I don't have much experiece with it but think it is
more of a plugin framework than Unity which is used for Dependency
Injection.

 

Craig

On Fri, Nov 5, 2010 at 11:54 PM, Anthony  wrote:

Is Microsoft Unity Application block a plugin architecture or should i use
another method to add a plugin feature to my asp.net app?

  Is your website being
IntelliXperienced?  | www.yougoingmyway.com ?
regards
Anthony (*12QWERNB*)

Is your website being IntelliXperienced?

 

 

ComVisible and Access client

[Greg Keogh]

I have to write a ComVisible DLL for an Access developer. My DLL will send
and receive messages over a Socket on behalf of the Access client. I
certainly know that VB6 clients can consume my ComVisible code, but Access
is unknown territory. So before I start any code I though it prudent to ask
some sanity checking questions here first.

 

I haven't been told which version of Access I'm programming against (I'm
waiting for a reply), but I think it's post 2000. 

 

. Can Access consume my registered ComVisible DLLs in the same way
VB6 does?

. Can the Access developer import a TLB to get a nice coding
experience?

. Can I give the Access client asynchronous callbacks when the
socket returns? That is, can Access deal with COM callbacks without coding
horror?

 

Tomorrow I plan to write a dummy ComVisible DLL and give it to the Access
developer as a proof of concept that my code can be consumed at all with
reasonable ease. I can't continue of course until that sanity check passes.
Any advice on this general matter of .NET vs Access would be most welcome.

 

Greg

RE: Passing a Form as owner to System.Windows.MessageBox.Show()

[Greg Keogh]

Sorry for the late reply,

 

I've had to popup MessageBox displays from various WPF components and
stumbled across a similar problem. You can ask for:

 

Window.GetWindow(DependencyObject foo);

 

So the argument can be a UserControl. Otherwise I use this property:

 

Application.Current.MainWindow

 

I'm not sure if I've answered your question.

 

Greg

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[David Kean]

I’d be surprised if it’s as large as DevDiv – it’s not the Framework that is 
huge, it’s the largest product (in code size) that we make; VS. ;)

I suspect a GB wouldn’t be bad, I easily pull down over 10 GB in my enlistments 
from TFS, so assumingly a DVCS could easily handle that, only with faster 
commits and history.

However, if you want the integration – TFS is definitely the way to go 
(however, I am biased ☺).

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Joseph Cooney
Sent: Friday, November 05, 2010 8:30 PM
To: ozDotNet
Cc: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

There is a mercurial vide from 2006 where they say some folks have gb-sized 
source trees. Mono use Git - which would be roughly the same size as a devdiv 
branch (an assumption based on the fact that they deliver equivalent 
functionality using the same language, unless you folk store VMs or something 
else big in your source tree that they don't). Linux kernel uses git, but they 
are well under a gb, as is Mozilla with hg.

On 06/11/2010, at 4:32 AM, David Kean 
mailto:david.k...@microsoft.com>> wrote:
How big are the databases that you are using? I’d imagine that there would be 
huge savings in using a DVCS for small self-contained repositories, however, 
there would be a given size where using one would no longer be an advantage. 
For example, I can’t imagine a DVCS working at Microsoft; a full enlistment in 
one branch in DevDiv is around 300 GB (times that by 100s of branches) – having 
everyone pull that down and all the history along with it, would not be fun.

From: ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Ryall
Sent: Friday, November 05, 2010 11:19 AM
To: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

I'm using svn again now after using git and hg for a few years (tfs was in 
there too - i don't want to talk about that).  I always liked svn and found it 
adequate but don't anymore.

There's nothing a DVCS provides that you can't live without - just as 64Kb of 
RAM was once perfectly adequate.

There are just a whole lot of things with DVCS that suddenly become easier or 
possible.  While you might not have considered these things earlier (because 
you couldn't), you really miss them when you can't.
They are insanely fast - especially git.  You will notice how fast they are 
every time you need to do a commit.  Insanely fast encourages more frequent 
commits.  The fact that after a clone, you end up with the entire history of a 
project locally (including every branch) in far less time than svn would take 
to check out a single code line (due to all the thousands of tiny control files 
it needs to create in every directory) is the winner for me.

Hosting is free or really cheap (bitbucket/github/launchpad).

For an open source project, fork/send pull request is a much lower barrier to 
entry for collaboration than checkout/email patch file.  If you accept a pull 
request, that person's commit becomes part of your codebase as them without you 
needing to provide direct commit access (as opposed to their changes being 
committed from a patch by you).

I prefer to avoid branching where possible but they make branching effortlessly 
easy.  Merging with git/hg is trivial and is properly tracked unlike with svn.  
Merging is always awful but git in particular seems to have some preternatural 
ability to help you get it right.

DVCS won't make you taller, more muscular or attractive though (i've tried - it 
really doesn't work) so use your best judgement.

On Wednesday, 3 November 2010 at 6:43 PM, silky wrote:
On Thu, Nov 4, 2010 at 12:37 PM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:


argumentative? silky? GTFO!

:)




Most of my experience with DVCS has been with
mercurial (hg) which I've used for about the last 2 years for my personal
stuff. Before that I used SVN. I think the difference (from my point of
view) is that hg works well in a super-set of configurations to TFS/SVN. If
you were a solo developer with TFS installed locally then hg probably
wouldn't be that much better (it certainly handles branching, merging and
backing up more cleanly than TFS/SVN). But most people don't work that  way
- the server is remote. If you want to look at the 'history' for a file or
do a diff it's a network operation. Checking out is a network operation (at
least for TFS it is...not sur e about SVN). In the case of TFS 2008 when the
server was off-line work ground to a halt. With hg sometimes there _is_ no
central server. I've had good experiences collaborating with other devs
using hg with no central server set up, just sending patches back and forth
for synchronization. You can set up your development processes such that
your DVCS is fairly centralized (like things would be with TFS/SVN) - devs
commit and push/pull often. Then