Re: HEADS UP: Fwd: Microsoft: Windows Azure - Activation Benefits
That's one of the more genuine looking scam emails I've seen. On Sun, Sep 11, 2011 at 3:56 PM, Glen Harvy g...@aquarius.com.au wrote: ** Hi, Last Friday I received a telephone call. The caller, a well spoken woman with a south-east asian accent asked to speak to me using my first and last name. They identified themselves as being from Microsoft Singapore and they wanted to know why I had not yet activated my MSDN free Azure offer. snipt Is that comic Sans? -- Meski http://courteous.ly/aAOZcv Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough - Adam Hills
Latest MS Sync Framework?
Looking at the sync framework home page ( http://msdn.microsoft.com/en-us/sync/bb736753) I see that CTP 4.0 (from October 2010) is listed. Is this really the last update - that seems pretty ancient? Or is there codeplex type releases that I should be looking at instead. It look like an interesting technology for off line phone applications. Also thinking about it, does anyone on the list use it or a competing technology? -- regards, Preet, Overlooking the Ocean, Auckland
RE: Latest MS Sync Framework?
Team blog seems to still active, might find more info there? http://blogs.msdn.com/b/sync/ Thanks Clint Colefax From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Preet Sangha Sent: Monday, 12 September 2011 1:38 PM To: ozDotNet Subject: Latest MS Sync Framework? Looking at the sync framework home page (http://msdn.microsoft.com/en-us/sync/bb736753) I see that CTP 4.0 (from October 2010) is listed. Is this really the last update - that seems pretty ancient? Or is there codeplex type releases that I should be looking at instead. It look like an interesting technology for off line phone applications. Also thinking about it, does anyone on the list use it or a competing technology? -- regards, Preet, Overlooking the Ocean, Auckland
RE: Latest MS Sync Framework?
Only just Looks like they've scrapped v4 and just realising the useful bits as a toolkit as source code! Nick Randolph | Built to Roam Pty Ltd | Microsoft MVP - Windows Phone Development | +61 412 413 425 | @btroam The information contained in this email is confidential. If you are not the intended recipient, you may not disclose or use the information in this email in any way. Built to Roam Pty Ltd does not guarantee the integrity of any emails or attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Built to Roam Pty Ltd. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Clint Colefax Sent: Monday, 12 September 2011 2:15 PM To: ozDotNet Subject: RE: Latest MS Sync Framework? Team blog seems to still active, might find more info there? http://blogs.msdn.com/b/sync/ Thanks Clint Colefax From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]mailto:[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Preet Sangha Sent: Monday, 12 September 2011 1:38 PM To: ozDotNet Subject: Latest MS Sync Framework? Looking at the sync framework home page (http://msdn.microsoft.com/en-us/sync/bb736753) I see that CTP 4.0 (from October 2010) is listed. Is this really the last update - that seems pretty ancient? Or is there codeplex type releases that I should be looking at instead. It look like an interesting technology for off line phone applications. Also thinking about it, does anyone on the list use it or a competing technology? -- regards, Preet, Overlooking the Ocean, Auckland
Re: Manually registering an export from a MEF plugin
Thanks Michael.
Your code works for me without specifying the type on the FuncIBar import.
The export on CreateBar() doesn't need to specify the type either.
On Sat, Sep 10, 2011 at 10:34 PM, Michael Minutillo
michael.minuti...@gmail.com wrote:
Sorry, you need to specify the type when importing a Func, you can't
leave it blank as I did in my example code (serves me right for not trying
it before posting)
On Sat, Sep 10, 2011 at 8:31 PM, Michael Minutillo
michael.minuti...@gmail.com wrote:
You can export a Func and then call it. Like this:
class BarFactory
{
[Import]
IBlah blah;
[Export(typeof(FuncIBar))]
IBar CreateBar()
{
return new Bar(blah);
}
}
class BarProvider
{
[Import]
private FuncIBar _factory;
[Export]
public IBar Bar { get { return _factory.Invoke(); } }
}
Michael M. Minutillo
Indiscriminate Information Sponge
http://codermike.com
On Sat, Sep 10, 2011 at 7:38 PM, Matt Siebert mlsieb...@gmail.comwrote:
I kind of like this approach, but does MEF allow an Export on a method?
If so then I suppose I could do something like:
class BarFactory
{
[Import]
IBlah blah;
[Export]
IBar CreateBar()
{
return new Bar(blah);
}
}
I can see how imports could be handled with David's approach though.
Thanks.
On Saturday, September 10, 2011, Michael Minutillo
michael.minuti...@gmail.com wrote:
One solution would be to add the following class to Foo.dll but it
means you're controlling the creation of Bar instead of getting MEF to do it
for you
class BarProvider
{
[Export(typeof(IBar))]
IBar ExportedBar = new Bar();
}
Michael M. Minutillo
Indiscriminate Information Sponge
http://codermike.com
On Fri, Sep 9, 2011 at 2:33 PM, Matt Siebert mlsieb...@gmail.com
wrote:
Hey folks,
I'm beginning to use MEF in a solution that involves a mix of .NET 3.5
and 4.0 projects. I'm using MEF in the 4.0 projects and I need to register
some exports that live in the 3.5 projects. The problem is I need to do
this from one of the plugin projects.
To illustrate this, imagine a console application such as...
class Program
{
static void Main(string[] args)
{
var program = new Program();
var catalog = new DirectoryCatalog(.);
using (var container = new CompositionContainer(catalog))
{
var batch = new CompositionBatch();
batch.AddPart(program);
container.Compose(batch);
program.Test();
}
}
[Import]
private IFoo foo = null;
public void Test()
{
Console.WriteLine(foo.Bar);
}
}
IFoo is in another DLL with a concrete implementation...
public interface IFoo
{
string Bar { get; }
}
[Export(typeof(IFoo))]
public class Foo : IFoo
{
[Import]
private IBar bar;
public string Bar
{
get { return Beer + bar.Foo; }
}
}
and finally, IBar is in a .NET 3.5 DLL that isn't using MEF...
public interface IBar
{
string Foo { get; }
}
public class Bar : IBar
{
public string Foo
{
get { return me; }
}
}
Is there a way to register an IBar export without the console
application referencing Bar.dll?
Foo.dll has a reference to Bar.dll and could register the export, but
in order to do this composition must occur first (so that the app can
discover Foo.dll) and that will fail since Foo's IBar import can't be
satisfied.
Cheers.
Re: Manually registering an export from a MEF plugin
Hmm. It appears I have been misinformed by the documentation.
Curse you, out of sync build artefacts! *shakes first as sky*
Michael M. Minutillo
Indiscriminate Information Sponge
http://codermike.com
On Mon, Sep 12, 2011 at 12:59 PM, Matt Siebert mlsieb...@gmail.com wrote:
Thanks Michael.
Your code works for me without specifying the type on the FuncIBar
import.
The export on CreateBar() doesn't need to specify the type either.
On Sat, Sep 10, 2011 at 10:34 PM, Michael Minutillo
michael.minuti...@gmail.com wrote:
Sorry, you need to specify the type when importing a Func, you can't
leave it blank as I did in my example code (serves me right for not trying
it before posting)
On Sat, Sep 10, 2011 at 8:31 PM, Michael Minutillo
michael.minuti...@gmail.com wrote:
You can export a Func and then call it. Like this:
class BarFactory
{
[Import]
IBlah blah;
[Export(typeof(FuncIBar))]
IBar CreateBar()
{
return new Bar(blah);
}
}
class BarProvider
{
[Import]
private FuncIBar _factory;
[Export]
public IBar Bar { get { return _factory.Invoke(); } }
}
Michael M. Minutillo
Indiscriminate Information Sponge
http://codermike.com
On Sat, Sep 10, 2011 at 7:38 PM, Matt Siebert mlsieb...@gmail.comwrote:
I kind of like this approach, but does MEF allow an Export on a method?
If so then I suppose I could do something like:
class BarFactory
{
[Import]
IBlah blah;
[Export]
IBar CreateBar()
{
return new Bar(blah);
}
}
I can see how imports could be handled with David's approach though.
Thanks.
On Saturday, September 10, 2011, Michael Minutillo
michael.minuti...@gmail.com wrote:
One solution would be to add the following class to Foo.dll but it
means you're controlling the creation of Bar instead of getting MEF to do
it
for you
class BarProvider
{
[Export(typeof(IBar))]
IBar ExportedBar = new Bar();
}
Michael M. Minutillo
Indiscriminate Information Sponge
http://codermike.com
On Fri, Sep 9, 2011 at 2:33 PM, Matt Siebert mlsieb...@gmail.com
wrote:
Hey folks,
I'm beginning to use MEF in a solution that involves a mix of .NET
3.5 and 4.0 projects. I'm using MEF in the 4.0 projects and I need to
register some exports that live in the 3.5 projects. The problem is I need
to do this from one of the plugin projects.
To illustrate this, imagine a console application such as...
class Program
{
static void Main(string[] args)
{
var program = new Program();
var catalog = new DirectoryCatalog(.);
using (var container = new CompositionContainer(catalog))
{
var batch = new CompositionBatch();
batch.AddPart(program);
container.Compose(batch);
program.Test();
}
}
[Import]
private IFoo foo = null;
public void Test()
{
Console.WriteLine(foo.Bar);
}
}
IFoo is in another DLL with a concrete implementation...
public interface IFoo
{
string Bar { get; }
}
[Export(typeof(IFoo))]
public class Foo : IFoo
{
[Import]
private IBar bar;
public string Bar
{
get { return Beer + bar.Foo; }
}
}
and finally, IBar is in a .NET 3.5 DLL that isn't using MEF...
public interface IBar
{
string Foo { get; }
}
public class Bar : IBar
{
public string Foo
{
get { return me; }
}
}
Is there a way to register an IBar export without the console
application referencing Bar.dll?
Foo.dll has a reference to Bar.dll and could register the export, but
in order to do this composition must occur first (so that the app can
discover Foo.dll) and that will fail since Foo's IBar import can't be
satisfied.
Cheers.
