Single instance WPF apps

[Peter O'Hanlon]

So, I'm updating my MVVM framework right now and one of the things I'm adding in is single instance support. Now, when I create a new instance I only want to allow the 1 instance, but allow the new instance to pass any command line arguments across. Now, in order to do this I'm looking to use WCF - but I wonder if it's too heavyweight; should I not just use inbuilt TCP. Any thoughts?

--
Peter O'Hanlon

[Marlon Grech]

Why not just have a named pipe and listen to it so that the other app can send a message in there?

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App

[Shawn Wildermuth]

Why not just the old trick of using a Mutex?

 

Thanks,

Shawn Wildermuth

http://wildermuth.com

 

Note: This was typed on a big ole laptop so any misspellings and punctuations are completely my fault…not my phone’s.

[Marlon Grech]

I refered to named pipes only for 

>> "but allow the new instance to pass any command line arguments across."

for maintaining a single instance I also believe the Mutex is good 

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App

[Michael Brown]

I agree with Marlon that Named Pipes is the way to go. WCF supports named pipes so it might help you abstract the usage but also might be a bit excessive for your needs.

[Sacha Barber]

As others have said Mutex all the way baby.

On Sat, Jul 31, 2010 at 8:25 PM, Peter O'Hanlon <pete.o...@gmail.com> wrote:

--
Sacha Barber
sacha....@gmail.com

[Peter O'Hanlon]

That's actually what I'm doing with WCF right now, but thinking about it, it's probably overkill (overengineered in other words - will devs really want to change bindings for this at a later stage?)

--
Peter O'Hanlon

[Peter O'Hanlon]

I'm already using the mutex for the single instance part - the named pipes I'm using are for passing the command line arguments across from separate instances. Initially I was using a Semaphore to do this, but I moved to pipes a couple of days ago using WCF, leaving room to change it to a different binding if I needed to.

--
Peter O'Hanlon

[Zhou Yong]

I've posted a sample on MSDN forum:

http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/e321cc4b-e2f3-474e-9575-bacbd2e83a60

MarcoZ

[Peter O'Hanlon]

Cheers Marco - I'll have a look. The approach I've taken is to derive from Application, and use a Mutex in the OnStartup method to control the access. If the new instance is a second instance, the command line arguments are passed back to the original instance on a pipe and the new instance terminates. I looked at using MMF but decided that named pipes were sufficient for my purposes.

--
Peter O'Hanlon

[Peter O'Hanlon]

That's how Excel works when you start it up. The command line arguments are normally file names.

On 1 August 2010 08:08, Sacha Barber <sacha....@gmail.com> wrote:

Sounds weird to me, so you have 1 instance that was started with certain command line args, and then you start another that affects the 1st instance. That's some weird requirement man.

Anyway another way altogether would be to use some sort of distributed messager, like Mass Transit, or Rhino Service Bus, we talked about these just the other day. The are like a distributed mediator in effect.

--

Sacha Barber
sacha....@gmail.com

--
Peter O'Hanlon

[Peter O'Hanlon]

I'm already doing that. I was just wondering really whether this was too heavyweight as it puts extra references into the client project.

On 1 August 2010 08:13, Brian Noyes <brian...@softinsight.com> wrote:

Yes exactly - it's called the named pipe binding in WCF, and then you get to leverage the clean programming model of WCF of objects calling objects instead of writing and reading custom messages to named pipes yourself, as well as having to set up that named pipe yourself.

Singleton WCF service at a known address (I.e. net.pipe://localhost/myapp), try to call it at startup (before starting your own host for one if not found), good to go. Can probably throw together a little example in 5 minutes for you a little later.

--
Peter O'Hanlon

[Brian Noyes]

If you are looking at it from an overhead perspective, I guess it depends on whether you think an extra 3M working set for loading System.ServiceModel into memory is going to matter to your users. The framework has to be on their machine to support it anyway, so not really any impact other than working set in my opinion.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Peter O'Hanlon
Sent: Sunday, August 01, 2010 9:19 AM
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] Single instance WPF apps

 

I'm already doing that. I was just wondering really whether this was too heavyweight as it puts extra references into the client project.

[Sacha Barber]

Sounds weird to me, so you have 1 instance that was started with certain command line args, and then you start another that affects the 1st instance. That's some weird requirement man.

Anyway another way altogether would be to use some sort of distributed messager, like Mass Transit, or Rhino Service Bus, we talked about these just the other day. The are like a distributed mediator in effect.

--
Sacha Barber
sacha....@gmail.com

[Glenn Block]

 So I would say use a combination of a mutex as a resource to ensure a single instance, and a memory mapped file for passing the params.

On Sat, Jul 31, 2010 at 9:15 PM, Glenn Block <glenn...@gmail.com> wrote:

Here's a link on memory mapped files in 4.0. If you are not using 4.0 you need to use Windows APIs to access it: http://msdn.microsoft.com/en-us/library/dd997372.aspx

On Sat, Jul 31, 2010 at 9:14 PM, Glenn Block <glenn...@gmail.com> wrote:

Mutex gives you the lock but how does it hangle sending across the params? You could use a memory mapped file for passing data. I believe we expose managed apis for it.

[Glenn Block]

Mutex gives you the lock but how does it hangle sending across the params? You could use a memory mapped file for passing data. I believe we expose managed apis for it.

On Sat, Jul 31, 2010 at 2:17 PM, Sacha Barber <sacha....@gmail.com> wrote:

[Glenn Block]

OK, send one over :-)

On Sun, Aug 1, 2010 at 12:24 AM, Brian Noyes <brian...@softinsight.com> wrote:

I'm shocked to see the new WCF dealer suggesting grunging around with multiple low level communications approaches when your stack is perfect for this. You need a bigger pitcher of WCF Kool Aid my friend.:)

[Brian Noyes]

I'm shocked to see the new WCF dealer suggesting grunging around with multiple low level communications approaches when your stack is perfect for this. You need a bigger pitcher of WCF Kool Aid my friend.:)

On Aug 1, 2010, at 6:17, Glenn Block <glenn...@gmail.com> wrote:

[Glenn Block]

I didn't recommend it because it seemed like the decision had already been made that it was too heavy :-)

On Sun, Aug 1, 2010 at 12:24 AM, Brian Noyes <brian...@softinsight.com> wrote:

[Sacha Barber]

Marco (Sheva) implementation looks cool, master of Remoting is that chap. Looks like it does what you want

--
Sacha Barber
sacha....@gmail.com

[Sacha Barber]

Suppose.

--
Sacha Barber
sacha....@gmail.com

[Brian Noyes]

Yes exactly - it's called the named pipe binding in WCF, and then you get to leverage the clean programming model of WCF of objects calling objects instead of writing and reading custom messages to named pipes yourself, as well as having to set up that named pipe yourself.

Singleton WCF service at a known address (I.e. net.pipe://localhost/myapp), try to call it at startup (before starting your own host for one if not found), good to go. Can probably throw together a little example in 5 minutes for you a little later.

On Jul 31, 2010, at 21:30, Marlon Grech <marlo...@gmail.com> wrote:

[Glenn Block]

You would basically have to write a com wrapper that called the API.

On Sat, Jul 31, 2010 at 10:08 PM, Shawn Wildermuth <shawn...@agilitrain.com> wrote:

Depends on the security context of the machine and the OS.  Remember that while COM objects work, if the underlying source is protected (e.g. FileSystemObject to peruse System32 on Windows 7) it will still throw a security exception. Not sure how this will impact Mapped Memory files but it might.

 

Thanks,

Shawn Wildermuth

http://wildermuth.com

 

Note: This was typed on a big ole laptop so any misspellings and punctuations are completely my fault…not my phone’s.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Glenn Block
Sent: Sunday, August 01, 2010 12:18 AM

To: wpf-di...@googlegroups.com

Subject: Re: [WPF Disciples] Single instance WPF apps

 

Interesting side note....with COM support in SL you could probably use memory mapped files to pass state between an inproc app and an SL one. Not sure you would want to...but cool that you can :-)

[Glenn Block]

Gotcha. That shouldn't effect using MMF for the original question (the important one) :-)

On Sat, Jul 31, 2010 at 10:08 PM, Shawn Wildermuth <shawn...@agilitrain.com> wrote:

Depends on the security context of the machine and the OS.  Remember that while COM objects work, if the underlying source is protected (e.g. FileSystemObject to peruse System32 on Windows 7) it will still throw a security exception. Not sure how this will impact Mapped Memory files but it might.

 

Thanks,

Shawn Wildermuth

http://wildermuth.com

 

Note: This was typed on a big ole laptop so any misspellings and punctuations are completely my fault…not my phone’s.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Glenn Block
Sent: Sunday, August 01, 2010 12:18 AM

To: wpf-di...@googlegroups.com

Subject: Re: [WPF Disciples] Single instance WPF apps

 

Interesting side note....with COM support in SL you could probably use memory mapped files to pass state between an inproc app and an SL one. Not sure you would want to...but cool that you can :-)

[Glenn Block]

It doesn't use FileSystemObject. It uses the windows API directly.

On Sat, Jul 31, 2010 at 10:08 PM, Shawn Wildermuth <shawn...@agilitrain.com> wrote:

Depends on the security context of the machine and the OS.  Remember that while COM objects work, if the underlying source is protected (e.g. FileSystemObject to peruse System32 on Windows 7) it will still throw a security exception. Not sure how this will impact Mapped Memory files but it might.

 

Thanks,

Shawn Wildermuth

http://wildermuth.com

 

Note: This was typed on a big ole laptop so any misspellings and punctuations are completely my fault…not my phone’s.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Glenn Block
Sent: Sunday, August 01, 2010 12:18 AM

To: wpf-di...@googlegroups.com

Subject: Re: [WPF Disciples] Single instance WPF apps

 

Interesting side note....with COM support in SL you could probably use memory mapped files to pass state between an inproc app and an SL one. Not sure you would want to...but cool that you can :-)

[Glenn Block]

Interesting side note....with COM support in SL you could probably use memory mapped files to pass state between an inproc app and an SL one. Not sure you would want to...but cool that you can :-)

[Shawn Wildermuth]

Depends on the security context of the machine and the OS.  Remember that while COM objects work, if the underlying source is protected (e.g. FileSystemObject to peruse System32 on Windows 7) it will still throw a security exception. Not sure how this will impact Mapped Memory files but it might.

 

Thanks,

Shawn Wildermuth

http://wildermuth.com

 

Note: This was typed on a big ole laptop so any misspellings and punctuations are completely my fault…not my phone’s.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Glenn Block
Sent: Sunday, August 01, 2010 12:18 AM
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] Single instance WPF apps

 

Interesting side note....with COM support in SL you could probably use memory mapped files to pass state between an inproc app and an SL one. Not sure you would want to...but cool that you can :-)

[Glenn Block]

Here's a link on memory mapped files in 4.0. If you are not using 4.0 you need to use Windows APIs to access it: http://msdn.microsoft.com/en-us/library/dd997372.aspx

On Sat, Jul 31, 2010 at 9:14 PM, Glenn Block <glenn...@gmail.com> wrote:

[Peter O'Hanlon]

It hadn't been made - I just wanted the perspective of others. Thanks guys - I'm sticking with the WCF stuff I've written.

--
Peter O'Hanlon

[Daniel Vaughan]

Hey guys,

Pete, you got me thinking about this, and so I took some time to
explore it further. I went with a MemoryMappedFile and an
EventWaitHandle.

http://danielvaughan.orpius.com/post/Enforcing-Single-Instance-WPF-Applications.aspx

Let me know what you think.

Cheers,
Daniel

[Peter O'Hanlon]

Very interesting Dan. Was there a reason you picked MMF over named pipes? I like your implementation, I like it a lot, but I think I'll stick with WCF and named pipes.

--
Peter O'Hanlon

[Sacha Barber]

I like that Daniel, nice and easy to follow

--
Sacha Barber
sacha....@gmail.com

[Sacha Barber]

No dependency on WCF is a good thing though right. Is this for Goldlight, which is MVVM framework, so I would not want a dependency on WCF for a MVVM framework, but that is just me.

--
Sacha Barber
sacha....@gmail.com

[Daniel Vaughan]

No reason in particular Pete. :)

On Aug 1, 7:33 pm, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote:
> Very interesting Dan. Was there a reason you picked MMF over named pipes? I
> like your implementation, I like it a lot, but I think I'll stick with WCF
> and named pipes.
>

> On 1 August 2010 17:44, Daniel Vaughan <dbvaug...@gmail.com> wrote:
>
>
>
> > Hey guys,
>
> > Pete, you got me thinking about this, and so I took some time to
> > explore it further. I went with a MemoryMappedFile and an
> > EventWaitHandle.
>

> >http://danielvaughan.orpius.com/post/Enforcing-Single-Instance-WPF-Ap...

[Daniel Vaughan]

Thank you sir.

On Aug 1, 7:41 pm, Sacha Barber <sacha.bar...@gmail.com> wrote:
> I like that Daniel, nice and easy to follow
>
>
>
> On Sun, Aug 1, 2010 at 5:44 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote:
> > Hey guys,
>
> > Pete, you got me thinking about this, and so I took some time to
> > explore it further. I went with a MemoryMappedFile and an
> > EventWaitHandle.
>

> >http://danielvaughan.orpius.com/post/Enforcing-Single-Instance-WPF-Ap...

>
> > Let me know what you think.
>
> > Cheers,
> > Daniel
>
> > On Jul 31, 9:25 pm, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote:
> > > So, I'm updating my MVVM framework right now and one of the things I'm
> > > adding in is single instance support. Now, when I create a new instance I
> > > only want to allow the 1 instance, but allow the new instance to pass any
> > > command line arguments across. Now, in order to do this I'm looking to
> > use
> > > WCF - but I wonder if it's too heavyweight; should I not just use inbuilt
> > > TCP. Any thoughts?
>
> > > --
> > > Peter O'Hanlon
>
> --
> Sacha Barber

> sacha.bar...@gmail.com

[Sacha Barber]

I did not realise that you could have system wide EventWaitHandle using a specific name. Thats cool

--
Sacha Barber
sacha....@gmail.com

[Jeremiah Morrill]

All this WCF gibber-gabber.  Where's the old school .NET remoting + named pipes love? ;)

--
Microsoft MVP - Client Application Development

HJT, Inc Software Developer

[Peter O'Hanlon]

That's what I've been debating (is WCF support a bad thing_ - and I'm now havering and looking the love on Dan's implementation. I may just be using a version of that.

--
Peter O'Hanlon

[Brian Noyes]

Alright, if you guys are going to start taking the "do it the hard way because it makes you cool", I am soo asking to be removed from the list.

--
-----------------------------------------
Brian Noyes
Chief Architect, IDesign Inc
Microsoft Regional Director / MVP
http://www.idesign.net
+1 703-447-3712
-----------------------------------------

[Peter O'Hanlon]

LMAO. To make my position clear though, I've been wondering whether requiring users to add the servicehost references for my MVVM framework is one that could put people off - honestly, I've been battling with myself on this one for 2 to 3 days now. It's the little things that cause the most grief.

--
Peter O'Hanlon

[Sacha Barber]

Personally I don't think you should have a dependency on ServiceHost Pete. Do it Dans way or Shevas Remoting way, I think it will sit better with most Goldlight users, honestly I do

On Sun, Aug 1, 2010 at 8:11 PM, Peter O'Hanlon <pete.o...@gmail.com> wrote:

LMAO. To make my position clear though, I've been wondering whether requiring users to add the servicehost references for my MVVM framework is one that could put people off - honestly, I've been battling with myself on this one for 2 to 3 days now. It's the little things that cause the most grief.

On 1 August 2010 20:06, Brian Noyes <brian...@softinsight.com> wrote:

Alright, if you guys are going to start taking the "do it the hard way because it makes you cool", I am soo asking to be removed from the list.

On Sun, Aug 1, 2010 at 8:32 PM, Peter O'Hanlon <pete.o...@gmail.com> wrote:

That's what I've been debating (is WCF sup port a bad thing_ - and I'm now havering and looking the love on Dan's implementation. I may just be using a version of that.

--
Peter O'Hanlon

--
Sacha Barber
sacha....@gmail.com

[Peter O'Hanlon]

I dropped the WCF dependency last night, and adopted a version of Dan's code. All due credit will go to him, and I will be talking through this in the articles I'm writing about Goldlight - topics like this tend to be really interesting, and I'd like to show people why I ended up making the decisions I did.

 

Again, thanks all - and I'm finally settled on my implementation.

--
Peter O'Hanlon

[Sacha Barber]

You should have a look at that codeproject one too, its a Microsoft solution, and looks cool too, and it will work in old versions of .NET while MemoryFile will only work in .NET4.0

--
Sacha Barber
sacha....@gmail.com

[Glenn Block]

I suggested MMF :-)

> --
> Peter O'Hanlon
>

[Sacha Barber]

So we have an attention seeker in our Midst...Tsk Tsk, tut tut. Back to the Restful WCF Mr Block.

--
Sacha Barber
sacha....@gmail.com

[Peter O'Hanlon]

And got slapped down for not recommending WCF;->. Don't worry, I will give credit where it's due.

--
Peter O'Hanlon

[Glenn Block]

lol