Here is a very good article regarding the Mutex solution. The approach described by the article is advantageous for two reasons.
First, it does not require a dependency on the Microsoft.VisualBasic assembly. If my project already had a dependency on that assembly, I would probably advocate using the approach shown in another answer. But as it is, I do not use the Microsoft.VisualBasic assembly, and I'd rather not add an unnecessary dependency to my project.
Second, the article shows how to bring the existing instance of the application to the foreground when the user tries to start another instance. That's a very nice touch that the other Mutex solutions described here do not address.
UPDATE
As of 8/1/2014, the article I linked to above is still active, but the blog hasn't been updated in a while. That makes me worry that eventually it might disappear, and with it, the advocated solution. I'm reproducing the content of the article here for posterity. The words belong solely to the blog owner at Sanity Free Coding.
Today I wanted to refactor some code that prohibited my application
from running multiple instances of itself.
Previously I had use System.Diagnostics.Process to search for an
instance of my myapp.exe in the process list. While this works, it
brings on a lot of overhead, and I wanted something cleaner.
Knowing that I could use a mutex for this (but never having done it
before) I set out to cut down my code and simplify my life.
In the class of my application main I created a static named Mutex:
static class Program
{
static Mutex mutex = new Mutex(true, "{8F6F0AC4-B9A1-45fd-A8CF-72F04E6BDE8F}");
[STAThread]
...
}
Having a named mutex allows us to stack synchronization across
multiple threads and processes which is just the magic I'm looking
for.
Mutex.WaitOne has an overload that specifies an amount of time for us
to wait. Since we're not actually wanting to synchronizing our code
(more just check if it is currently in use) we use the overload with
two parameters: Mutex.WaitOne(Timespan timeout, bool exitContext).
Wait one returns true if it is able to enter, and false if it wasn't.
In this case, we don't want to wait at all; If our mutex is being
used, skip it, and move on, so we pass in TimeSpan.Zero (wait 0
milliseconds), and set the exitContext to true so we can exit the
synchronization context before we try to aquire a lock on it. Using
this, we wrap our Application.Run code inside something like this:
static class Program
{
static Mutex mutex = new Mutex(true, "{8F6F0AC4-B9A1-45fd-A8CF-72F04E6BDE8F}");
[STAThread]
static void Main() {
if(mutex.WaitOne(TimeSpan.Zero, true)) {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
mutex.ReleaseMutex();
} else {
MessageBox.Show("only one instance at a time");
}
}
}
So, if our app is running, WaitOne will return false, and we'll get a
message box.
Instead of showing a message box, I opted to utilize a little Win32 to
notify my running instance that someone forgot that it was already
running (by bringing itself to the top of all the other windows). To
achieve this I used PostMessage to broadcast a custom message to every
window (the custom message was registered with RegisterWindowMessage
by my running application, which means only my application knows what
it is) then my second instance exits. The running application instance
would receive that notification and process it. In order to do that, I
overrode WndProc in my main form and listened for my custom
notification. When I received that notification I set the form's
TopMost property to true to bring it up on top.
Here is what I ended up with:
static class Program
{
static Mutex mutex = new Mutex(true, "{8F6F0AC4-B9A1-45fd-A8CF-72F04E6BDE8F}");
[STAThread]
static void Main() {
if(mutex.WaitOne(TimeSpan.Zero, true)) {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
mutex.ReleaseMutex();
} else {
// send our Win32 message to make the currently running instance
// jump on top of all the other windows
NativeMethods.PostMessage(
(IntPtr)NativeMethods.HWND_BROADCAST,
NativeMethods.WM_SHOWME,
IntPtr.Zero,
IntPtr.Zero);
}
}
}
// this class just wraps some Win32 stuff that we're going to use
internal class NativeMethods
{
public const int HWND_BROADCAST = 0xffff;
public static readonly int WM_SHOWME = RegisterWindowMessage("WM_SHOWME");
[DllImport("user32")]
public static extern bool PostMessage(IntPtr hwnd, int msg, IntPtr wparam, IntPtr lparam);
[DllImport("user32")]
public static extern int RegisterWindowMessage(string message);
}
- Form1.cs (front side partial)
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
protected override void WndProc(ref Message m)
{
if(m.Msg == NativeMethods.WM_SHOWME) {
ShowMe();
}
base.WndProc(ref m);
}
private void ShowMe()
{
if(WindowState == FormWindowState.Minimized) {
WindowState = FormWindowState.Normal;
}
// get our current "TopMost" value (ours will always be false though)
bool top = TopMost;
// make our form jump to the top of everything
TopMost = true;
// set it back to whatever it was
TopMost = top;
}
}
Unfortunately there is no one great MVVM example app that does everything, and there are a lot of different approaches to doing things. First, you might want to get familiar with one of the app frameworks out there (Prism is a decent choice), because they provide you with convenient tools like dependency injection, commanding, event aggregation, etc to easily try out different patterns that suit you.
The prism release:
http://www.codeplex.com/CompositeWPF
It includes a pretty decent example app (the stock trader) along with a lot of smaller examples and how to's. At the very least it's a good demonstration of several common sub-patterns people use to make MVVM actually work. They have examples for both CRUD and dialogs, I believe.
Prism isn't necessarily for every project, but it's a good thing to get familiar with.
CRUD:
This part is pretty easy, WPF two way bindings make it really easy to edit most data. The real trick is to provide a model that makes it easy to set up the UI. At the very least you want to make sure that your ViewModel (or business object) implements INotifyPropertyChanged
to support binding and you can bind properties straight to UI controls, but you may also want to implement IDataErrorInfo
for validation. Typically, if you use some sort of an ORM solution setting up CRUD is a snap.
This article demonstrates simple crud operations:
http://dotnetslackers.com/articles/wpf/WPFDataBindingWithLINQ.aspx
It is built on LinqToSql, but that is irrelevant to the example - all that is important is that your business objects implement INotifyPropertyChanged
(which classes generated by LinqToSql do). MVVM is not the point of that example, but I don't think it matters in this case.
This article demonstrates data validation
http://blogs.msdn.com/wpfsdk/archive/2007/10/02/data-validation-in-3-5.aspx
Again, most ORM solutions generate classes that already implement IDataErrorInfo
and typically provide a mechanism to make it easy to add custom validation rules.
Most of the time you can take an object(model) created by some ORM and wrap it in a ViewModel that holds it and commands for save/delete - and you're ready to bind UI straight to the model's properties.
The view would look like something like this (ViewModel has a property Item
that holds the model, like a class created in the ORM):
<StackPanel>
<StackPanel DataContext=Item>
<TextBox Text="{Binding FirstName, Mode=TwoWay, ValidatesOnDataErrors=True}" />
<TextBox Text="{Binding LastName, Mode=TwoWay, ValidatesOnDataErrors=True}" />
</StackPanel>
<Button Command="{Binding SaveCommand}" />
<Button Command="{Binding CancelCommand}" />
</StackPanel>
Dialogs:
Dialogs and MVVM are a bit tricky. I prefer to use a flavor of the Mediator approach with dialogs, you can read a little more about it in this StackOverflow question:
WPF MVVM dialog example
My usual approach, which is not quite classic MVVM, can be summarized as follows:
A base class for a dialog ViewModel that exposes commands for commit and cancel actions, an event to lets the view know that a dialog is ready to be closed, and whatever else you will need in all of your dialogs.
A generic view for your dialog - this can be a window, or a custom "modal" overlay type control. At its heart it is a content presenter that we dump the viewmodel into, and it handles the wiring for closing the window - for example on data context change you can check if the new ViewModel is inherited from your base class, and if it is, subscribe to the relevant close event (the handler will assign the dialog result). If you provide alternative universal close functionality (the X button, for instance), you should make sure to run the relevant close command on the ViewModel as well.
Somewhere you need to provide data templates for your ViewModels, they can be very simple especially since you probably have a view for each dialog encapsulated in a separate control. The default data template for a ViewModel would then look something like this:
<DataTemplate DataType="{x:Type vmodels:AddressEditViewModel}">
<views:AddressEditView DataContext="{Binding}" />
</DataTemplate>
The dialog view needs to have access to these, because otherwise it won't know how to show the ViewModel, aside from the shared dialog UI its contents are basically this:
<ContentControl Content="{Binding}" />
The implicit data template will map the view to the model, but who launches it?
This is the not-so-mvvm part. One way to do it is to use a global event. What I think is a better thing to do is to use an event aggregator type setup, provided through dependency injection - this way the event is global to a container, not the whole app. Prism uses the unity framework for container semantics and dependency injection, and overall I like Unity quite a bit.
Usually, it makes sense for the root window to subscribe to this event - it can open the dialog and set its data context to the ViewModel that gets passed in with a raised event.
Setting this up in this way lets ViewModels ask the application to open a dialog and respond to user actions there without knowing anything about the UI so for the most part the MVVM-ness remains complete.
There are times, however, where the UI has to raise the dialogs, which can make things a bit trickier. Consider for example, if the dialog position depends on the location of the button that opens it. In this case you need to have some UI specific info when you request a dialog open. I generally create a separate class that holds a ViewModel and some relevant UI info. Unfortunately some coupling seems unavoidable there.
Pseudo code of a button handler that raises a dialog which needs element position data:
ButtonClickHandler(sender, args){
var vm = DataContext as ISomeDialogProvider; // check for null
var ui_vm = new ViewModelContainer();
// assign margin, width, or anything else that your custom dialog might require
...
ui_vm.ViewModel = vm.SomeDialogViewModel; // or .GetSomeDialogViewModel()
// raise the dialog show event
}
The dialog view will bind to position data, and pass the contained ViewModel to the inner ContentControl
. The ViewModel itself still doesn't know anything about the UI.
In general I don't make use of the DialogResult
return property of the ShowDialog()
method or expect the thread to block until the dialog is closed. A non-standard modal dialog doesn't always work like that, and in a composite environment you often don't really want an event handler to block like that anyhow. I prefer to let the ViewModels deal with this - the creator of a ViewModel can subscribe to its relevant events, set commit/cancel methods, etc, so there is no need to rely on this UI mechanism.
So instead of this flow:
// in code behind
var result = somedialog.ShowDialog();
if (result == ...
I use:
// in view model
var vm = new SomeDialogViewModel(); // child view model
vm.CommitAction = delegate { this.DoSomething(vm); } // what happens on commit
vm.CancelAction = delegate { this.DoNothing(vm); } // what happens on cancel/close (optional)
// raise dialog request event on the container
I prefer it this way because most of my dialogs are non-blocking pseudo-modal controls and doing it this way seems more straightforward than working around it. Easy to unit test as well.
Best Answer
WinRT is basically a collection of COM objects that wrap a bunch of Win32 API', exposed as CLI-compliant assemblies.
Microsoft modified their C++ compiler to consume and generate ECMA 335 (i.e. CLI) metadata rather than the more traditional and (largely) C++/COM-only MIDL or lib file formats. Microsoft also modified their "Chakra" Javascript engine to also consume and emit CLI metadata.
This means that when targeting WinRT, Javascript and C++ code, along with .NET languages, of course, can consume CLI-compliant (i.e. .NET) assemblies and can emit CLI-compatible (i.e. .NET) assemblies.
So, one can write WinRT code in C++, any .NET language (i.e. C#, VB.NET, F#, Iron*, etc) and in Javascript.
The WinRT API's will be VERY familiar to you if you've ever written any .NET code. The Windows team actually sought the help & guidance of the .NET Framework design team when designing WinRT, so the same design guidelines that have guided the entire .NET framework team and most of the .NET community for the last 11 years have been applied to the WinRT API's.
WinRT's primary impact is that it replaces System.IO's file, network, stream IO classes with similar API's but which ONLY support async IO. This means that you will not be able to write apps that block threads while they wait for calls to the filesystem or external systems via the network to return unless you take explicit steps to do so.
This is a GOOD thing.
Luckily, the new async/await features of C# v5 & VB.NET v.next, along with specific support for C++ mean that you don't have to go and fundamentally change how you write code in this new async world - typically you just need to add an "async" keyword to method signatures that call async API's and then use the 'await' keyword prefixing each async API call.
I STRONGLY encourage you to watch Anders Hejlsberg's session which should make this whole thing very clear. While you're there, I also encourage you to watch several of the other //BUILD sessions, especially Harry Pierson's talk on using WinRT with C# & VB.NET and Mads' session on Async Made Simple in C# and VB.
I'd also recommend that you take a look at the improved Win8/WinRT platform architecture diagram that I blogged a few weeks back which should make things a little clearer.
As for .NET itself, as I articulate in my post above, .NET is not "going away". While a few of the .NET API's will be prohibited in WinRT apps (i.e. blocking IO API's), most of the API's you depend upon remain and are fully accessible.
Regarding Silverlight: Silverlight is a browser plug-in. It's a modified-subset of WPF and offers some very powerful and attractive features. So much so, in fact, that the Silverlight XAML engine was moved into the core Windows team and is used for most of the Metro UI rendering in Windows8 - even by the OS itself!
The net result is that most of your Silverlight code will run just fine with barely any modification, other than just changing a few 'using' namespaces.
There are a ton of XAML-focussed sessions from BUILD available to watch here.
With regards backward compatibility, aim to:
Frankly, I don't think it's Microsoft's job to write every framework for every scenario. There are several MVVP approaches/frameworks out there in the wild from various people with various pro's and con's. And if you don't find one then create one and stick it up on GITHub and become famous ;)
Above all, though, there's little stopping you from downloading and trying Win8 Consumer Preview & Dev11 Beta. Go get them and try them out - I think you'll find them very refreshing :)
HTH.
You can find the WinRT API surface area enumerated here in some detail. The core WCF API's are enumerated here.
Note, however, that Microsoft is strongly recommending against using network coomms to communicate between Metro apps and other metro apps or desktop apps/services on the same machine. Read this SO question & Kate Gregory's answer - she links to a video where this scenario is discussed in detail.
If you want to communicate with off-box network services, then you have a wide variety of options including WCF, sockets, etc.
Regarding RIA: Microsoft are currently saying that if you want data, you'll need to get it via a service rather than directly from a DB. There's no ADO.NET for Metro and the recommendation is to surface data via OData, JSON, XML/HTTP, etc. Data as a service is very much a RIA scenario, so I expect RIA to be well supported for Metro apps. Here's a BUILD session on this very subject which may shed more light.
Only you can tell whether or not your specific scenarios are supported in WinRT. I think your best bet would be to download the bits and start exploring.
This guidance includes updates to Prism/Kona and also includes EntLib6 & Unity3 (IoC). I encourage anyone interested in this space to study the published materials and reference apps - there is some great stuff in there :)