Develop Reference

Launch a WPF application in a DLL from a console application exe

Currently I have two separate C# projects under the same solution, let's call it Window.exe and Console.exe. Window.exe is a WPF MVVM application that works well standalone.
To eliminate one small issue, my goal is to convert Window.exe into Window.dll, and then use Console.exe to load Window.dll. I tried to call App.Run(), or move the routine in App_Startup, that is used to launch the main window onto a separate method and called it. The new thread that runs Window.dll couldn't really last. It was able to populate the GUI when I stepped into it in debug, but I could not interact with it.
Any ideas on how I should proceed?

I was able to accomplish this by doing two things:
You need to mark the Main method in your console applicaiton as an STAThread method because the UI will need to be on an STA thread. If you don't, you'll get an exception when the constructor for the main window is called.
Make sure you also call InitializeComponent() before Run(). If you don't, the app will run, but the window won't have been set up first.
I was able to get this to work in a solution where I, as well, have a WPF main application and console application for testing things:
[STAThread]
static void Main(string[] args)
{
WpfApp.App app = new WpfApp.App();
app.InitializeComponent();
app.Run();
}

Closing Applications

What is best practice when closing a C# application?
I have read that you can use:
Environment.Exit(0); or Application.Exit();
But what is the difference?
Furthermore, with regards to Environment.Exit(0), I have used exit codes before when working with Java but have never fully understood their purpose. What role do they play when exiting an application in C#?

System.Windows.Forms.Application.Exit() - Informs all message pumps that they must terminate, and then closes all application windows after the messages have been processed. This method stops all running message loops on all threads and closes all windows of the application. This method does not force the application to exit. The Exit() method is typically called from within a message loop, and forces Run() to return. To exit a message loop for the current thread only, call ExitThread(). This is the call to use if you are running a Windows Forms application. As a general guideline, use this call if you have called System.Windows.Forms.Application.Run().
System.Environment.Exit(exitCode) - Terminates this process and gives the underlying operating system the specified exit code. This call requires that you have SecurityPermissionFlag.UnmanagedCode permissions. If you do not, a SecurityException error occurs. This is the call to use if you are running a console application.
I hope it is best to use Application.Exit
See also these links:
Application.Exit() vs Application.ExitThread() vs Environment.Exit()
http://geekswithblogs.net/mtreadwell/archive/2004/06/06/6123.aspx

Application.Exit is for Windows Forms applications - it informs all message pumps that they should terminate, waits for them to finish processing events and then terminates the application. Note that it doesn't necessarily force the application to exit.
Environment.Exit is applicable for all Windows applications, however it is mainly intended for use in console applications. It immediately terminates the process with the given exit code.
In general you should use Application.Exit in Windows Forms applications and Environment.Exit in console applications, (although I prefer to let the Main method / entry point run to completion rather than call Environment.Exit in console applications).
For more detail see the MSDN documentation.

What role do they play when exiting an application in C#?
The same as every other application. Basically they get returned to the caller. Irrelvant if ythe start was an iicon double click. Relevant is the call is a batch file that decides whether the app worked on the return code. SO, unless you write a program that needs this, the return dcode IS irrelevant.
But what is the difference?
One comes from environment one from the System.Windows.Forms?.Application. Functionall there should not bbe a lot of difference.

for me best solotion this is
Thread.CurrentThread.Abort();
and force close app.

Try this
System.Windows.Application.Current.Shutdown();
It is work also with NotifyIcon. Place this code in App.xaml.cs
'
protected override void OnExit(ExitEventArgs e)
{
base.OnExit(e);
App.nIcon.Visible = false;
}

Find out if running in WPF or console mode (c#)

Well
this is a really simple question, the search tearms are just not that great.
How do I check in some library if I am currently running as a console application, vs. a WPF window application?
Thanks for any tips,
Chris

You can check whether the current thread is a WPF UI thread by checking Dispatcher.Current.

There's more, what if your library method is called from a worker thread? You didn't tell why you need to know, preventing a good answer. One approach is that the app that uses your library never has any trouble knowing whether its console or WPF. Expose a property to allow it to tell you. Another is using events so the app can simply implement the event handler to its liking. Dependency Injection is another.

You can check if the executed statements are running in a WPF host with the following statement:
if (System.Windows.Application.Current != null)
{
//statements for WPF mode
}
else
{
//statements for non WPF mode...
}
For this you must reference PresentationFramework.dll

ILDasm will have an entry in the manifest as follows :
.subsystem 0x0003 // WINDOWS_CUI
.subsystem 0x0002 // WINDOWS_GUI
based on the subsystemtype you can tell if its GUI or CUI.
This information is also available from the following command :
dumpbin ConsoleApplication1.exe /headers
From your library query for entry assembly and get its full path(Assembly.GetEntryAssembly().CodeBase) and then you can issue any of these command to know the subsystem.

Console and Windows Forms in C#

Ok I'm creating an application with a plugin architecture and the application would be able to run without a GUI in other words the GUI is really optional... and if the user decides to use the GUI the console is just hidden.
I can create the form in the console by calling one of the plugins method, but as soon the Window is created the console program keeps waiting until the window is closed... is there a way to create the form so that the console doesn't have to wait, it should keep working on it's own stuff and just notify the gui with some info?

Why don't you keep the windows forms application as a seperate executable and call process.start() ?
For example
Process.Start("c:\yourwindowsformsapplication.exe");
You can quit your console application or continue other work within the console application once you start the windowsapplication.exe.
And use remoting to communicate between both the applications.
or....
Create a new thread and call your form.show() within a new thread
Example :
Form frm=new form();
Thread th=new Thread(frm.show);
th.start();

Are you creating and then showing the form using ShowDialog()? If so, that's why the console app is waiting for the form to close. Try showing the form using Show() instead - Show() is a non-blocking call that will return program execution to the next line.

'Application.Restart' not working in ClickOnce deployed application [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why is Application.Restart() not reliable?
I pulled the code straight from MSDN. This updates my application, but Restart() does not work. The application shuts down, but it does not restart.
I added a MenuItem to my Form to validate that Restart() works at all:
private void restartToolStripMenuItem_Click(object sender, EventArgs e)
{
Application.Restart();
}
This will restart the application (of course, it performs no updates and is user initiated, so it is fairly useless).
I have nothing else going on with this application. No event handlers for the Form on shutdown, nothing. This is the most basic Windows Forms application I could build (it just displays a resource JPEG in an ImagePanel).
Why does Restart() not work here?

Is your application Windows Forms or WPF? Because Application.Restart only exists in the Windows Forms Application object (System.Windows.Forms.Application) and is not supported by applications running under the WPF Application (System.Windows.Applications). You can still call it, but as the application context is different, it doesn't work.

If you are using a Mutex, or something of the like to ensure only one instance of the application is running at a time, that be causing this issue.

Try wrapping it with a BeginInvoke just in case it's not on the main STA thread.

Are you sure that you're calling Application.Restart from the main form? If you call a form with .ShowDialog and then from that form call Application.Restart, it won't work because the .ShowDialog causes the dialog form to run on a separate thread.

Try to raise a new process, maybe that can workaround it:
Process.Start(Application.ExecutablePath);