When you install a ClickOnce application, the program runs after the install. Is it possible to install without running?
I know I can use a setup and deployment project and create an installer, but I'd prefer to use ClickOnce.
I guess you could fake it. Introduce an "IsInstalled" boolean property, defaulted to false. Then in Program.cs, change your Main() method to look like this:
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
if (!Properties.Settings.Default.IsInstalled)
{
Properties.Settings.Default.IsInstalled = true;
Properties.Settings.Default.Save();
MessageBox.Show("Install Complete");
return;
}
Application.Run(new Form1());
}
So now when the app is first installed, it checks that property and simply displays a message to the user and then quits.
If you wanted to get tricky then you could look at parsing the Activation URI for the deployment and have a URI parameter which specifies whether the program should run when it's first installed or just close silently.
You can do this by editing the application manifest in Mage. There is a checkbox to stop the application running after installation.
If you are not comfortable editing a manifest manually or with Mage then you can use the built-in deployment class to check whether this is the first time the application has run.
using System.Deployment.Application
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
if (ApplicationDeployment.CurrentDeployment.IsFirstRun)
{
MessageBox.Show("Install Complete");
return;
}
Application.Run(new Form1());
}
After trying all the suggested solutions and still running into the same problems, I fiddled with this for a while and combined several solutions to one that actually works.
The problem with just setting an "isInstalled" property is the value is retained after upgrades, so every time you install the new version, it runs the app again. But using an application manifest file and Mage is just too much work and too complicated just to solve this little problem.
So what I did was acquire the current build # of the running version of the app, save that to a property, then check the property against the running version each time. This works because each publish increments the version #.
1) Change your Assembly version to use wildcards in AssemblyInfo.cs:
[assembly: AssemblyVersion("1.0.*")]
2) If that throws a "Deterministic" error on Build, open your .csproj file and set Deterministic to false in the PropertyGroup section
<Deterministic>false</Deterministic>
3) Add this fool-proof function to acquire the running assembly version:
private Version GetRunningVersion()
{
try
{
return System.Deployment.Application.ApplicationDeployment.CurrentDeployment.CurrentVersion;
}
catch
{
return System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
}
}
4) In your project's properties, open the Settings tab, and add a setting named lastVersion (String, User). Leave the Value empty.
5) Add this property to use to determine whether this is the first time the application is running after installation.
private bool isFirstRun
{
get { return Properties.Settings.Default.lastVersion != GetRunningVersion().ToString(); }
}
6) Then in your code, add this after you check for isFirstRun:
if (isFirstRun)
{
Properties.Settings.Default.lastVersion = GetRunningVersion().ToString();
Properties.Settings.Default.Save();
}
Related
When I create a new project, I get a strange behavior for unhandled exceptions. This is how I can reproduce the problem:
1) create a new Windows Forms Application (C#, .NET Framework 4, VS2010)
2) add the following code to the Form1_Load handler:
int vara = 5, varb = 0;
int varc = vara / varb;
int vard = 7;
I would expect that VS breaks and shows an unhandled exception message at the second line. However, what happens is that the third line is just skipped without any message and the application keeps running.
I don't have this problem with my existing C# projects. So I guess that my new projects are created with some strange default settings.
Does anyone have an idea what's wrong with my project???
I tried checking the boxes in Debug->Exceptions. But then executions breaks even if I handle the exception in a try-catch block; which is also not what I want. If I remember correctly, there was a column called "unhandled exceptions" or something like this in this dialog box, which would do excatly what I want. But in my projects there is only one column ("Thrown").
This is a nasty problem induced by the wow64 emulation layer that allows 32-bit code to run on the 64-bit version of Windows 7. It swallows exceptions in the code that runs in response to a notification generated by the 64-bit window manager, like the Load event. Preventing the debugger from seeing it and stepping in. This problem is hard to fix, the Windows and DevDiv groups at Microsoft are pointing fingers back and forth. DevDiv can't do anything about it, Windows thinks it is the correct and documented behavior, mysterious as that sounds.
It is certainly documented but just about nobody understands the consequences or thinks it is reasonable behavior. Especially not when the window procedure is hidden from view of course, like it is in any project that uses wrapper classes to hide the window plumbing. Like any Winforms, WPF or MFC app. Underlying issue is Microsoft could not figure out how to flow exceptions from 32-bit code back to the 64-bit code that triggered the notification back to 32-bit code that tries to handle or debug the exception.
It is only a problem with a debugger attached, your code will bomb as usual without one.
Project > Properties > Build tab > Platform target = AnyCPU and untick Prefer 32-bit. Your app will now run as a 64-bit process, eliminating the wow64 failure mode. Some consequences, it disables Edit + Continue for VS versions prior to VS2013 and might not always be possible when you have a dependency on 32-bit code.
Other possible workarounds:
Debug > Exceptions > tick the Thrown box for CLR exceptions to force the debugger to stop at the line of code that throws the exception.
Write try/catch in the Load event handler and failfast in the catch block.
Use Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) in the Main() method so that the exception trap in the message loop isn't disabled in debug mode. This however makes all unhandled exceptions hard to debug, the ThreadException event is pretty useless.
Consider if your code really belongs in the Load event handler. It is very rare to need it, it is however very popular in VB.NET and a swan song because it is the default event and a double-click trivially adds the event handler. You only ever really need Load when you are interested in the actual window size after user preferences and autoscaling is applied. Everything else belongs in the constructor.
Update to Windows 8 or later, they have this wow64 problem solved.
In my experience, I only see this issue when I'm running with a debugger attached. The application behaves the same when run standalone: the exception is not swallowed.
With the introduction of KB976038, you can make this work as you'd expect again. I never installed the hotfix, so I'm assuming it came as part of Win7 SP1.
This was mentioned in this post:
The case of the disappearing OnLoad exception – user-mode callback exceptions in x64
Here's some code that will enable the hotfix:
public static class Kernel32
{
public const uint PROCESS_CALLBACK_FILTER_ENABLED = 0x1;
[DllImport("Kernel32.dll")]
public static extern bool SetProcessUserModeExceptionPolicy(UInt32 dwFlags);
[DllImport("Kernel32.dll")]
public static extern bool GetProcessUserModeExceptionPolicy(out UInt32 lpFlags);
public static void DisableUMCallbackFilter() {
uint flags;
GetProcessUserModeExceptionPolicy(out flags);
flags &= ~PROCESS_CALLBACK_FILTER_ENABLED;
SetProcessUserModeExceptionPolicy(flags);
}
}
Call it at the beginning of your application:
[STAThread]
static void Main()
{
Kernel32.DisableUMCallbackFilter();
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
I've confirmed (with the the simple example shown below) that this works, just as you'd expect.
protected override void OnLoad(EventArgs e) {
throw new Exception("BOOM"); // This will now get caught.
}
So, what I don't understand, is why it was previously impossible for the debugger to handle crossing kernel-mode stack frames, but with this hotfix, they somehow figured it out.
As Hans mentions, compile the application and run the exe without a debugger attached.
For me the problem was changing a Class property name that a BindingSource control was bound to. Running without the IDE I was able to see the error:
Cannot bind to the property or column SendWithoutProofReading on the
DataSource. Parameter name: dataMember
Fixing the BindingSource control to bind to the updated property name resolved the problem:
I'm using WPF and ran into this same problem. I had tried Hans 1-3 suggestions already, but didn't like them because studio wouldn't stop at where the error was (so I couldn't view my variables and see what was the problem).
So I tried Hans' 4th suggestion. I was suprised at how much of my code could be moved to the MainWindow constructor without any issue. Not sure why I got in the habit of putting so much logic in the Load event, but apparently much of it can be done in the ctor.
However, this had the same problem as 1-3. Errors that occur during the ctor for WPF get wrapped into a generic Xaml exception. (an inner exception has the real error, but again I wanted studio to just break at the actual trouble spot).
What ended up working for me was to create a thread, sleep 50ms, dispatch back to main thread and do what I need...
void Window_Loaded(object sender, RoutedEventArgs e)
{
new Thread(() =>
{
Thread.Sleep(50);
CrossThread(() => { OnWindowLoaded(); });
}).Start();
}
void CrossThread(Action a)
{
this.Dispatcher.BeginInvoke(a);
}
void OnWindowLoaded()
{
...do my thing...
This way studio would break right where an uncaught exception occurs.
A simple work-around could be if you can move your init code to another event like as Form_Shown which called later than Form_Load, and use a flag to run startup code at first form shown:
bool firstLoad = true; //flag to detect first form_shown
private void Form1_Load(object sender, EventArgs e)
{
//firstLoad = true;
//dowork(); //not execute initialization code here (postpone it to form_shown)
}
private void Form1_Shown(object sender, EventArgs e)
{
if (firstLoad) //simulate Form-Load
{
firstLoad = false;
dowork();
}
}
void dowork()
{
var f = File.OpenRead(#"D:\NoSuchFile756.123"); //this cause an exception!
}
When I create a new project, I get a strange behavior for unhandled exceptions. This is how I can reproduce the problem:
1) create a new Windows Forms Application (C#, .NET Framework 4, VS2010)
2) add the following code to the Form1_Load handler:
int vara = 5, varb = 0;
int varc = vara / varb;
int vard = 7;
I would expect that VS breaks and shows an unhandled exception message at the second line. However, what happens is that the third line is just skipped without any message and the application keeps running.
I don't have this problem with my existing C# projects. So I guess that my new projects are created with some strange default settings.
Does anyone have an idea what's wrong with my project???
I tried checking the boxes in Debug->Exceptions. But then executions breaks even if I handle the exception in a try-catch block; which is also not what I want. If I remember correctly, there was a column called "unhandled exceptions" or something like this in this dialog box, which would do excatly what I want. But in my projects there is only one column ("Thrown").
This is a nasty problem induced by the wow64 emulation layer that allows 32-bit code to run on the 64-bit version of Windows 7. It swallows exceptions in the code that runs in response to a notification generated by the 64-bit window manager, like the Load event. Preventing the debugger from seeing it and stepping in. This problem is hard to fix, the Windows and DevDiv groups at Microsoft are pointing fingers back and forth. DevDiv can't do anything about it, Windows thinks it is the correct and documented behavior, mysterious as that sounds.
It is certainly documented but just about nobody understands the consequences or thinks it is reasonable behavior. Especially not when the window procedure is hidden from view of course, like it is in any project that uses wrapper classes to hide the window plumbing. Like any Winforms, WPF or MFC app. Underlying issue is Microsoft could not figure out how to flow exceptions from 32-bit code back to the 64-bit code that triggered the notification back to 32-bit code that tries to handle or debug the exception.
It is only a problem with a debugger attached, your code will bomb as usual without one.
Project > Properties > Build tab > Platform target = AnyCPU and untick Prefer 32-bit. Your app will now run as a 64-bit process, eliminating the wow64 failure mode. Some consequences, it disables Edit + Continue for VS versions prior to VS2013 and might not always be possible when you have a dependency on 32-bit code.
Other possible workarounds:
Debug > Exceptions > tick the Thrown box for CLR exceptions to force the debugger to stop at the line of code that throws the exception.
Write try/catch in the Load event handler and failfast in the catch block.
Use Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) in the Main() method so that the exception trap in the message loop isn't disabled in debug mode. This however makes all unhandled exceptions hard to debug, the ThreadException event is pretty useless.
Consider if your code really belongs in the Load event handler. It is very rare to need it, it is however very popular in VB.NET and a swan song because it is the default event and a double-click trivially adds the event handler. You only ever really need Load when you are interested in the actual window size after user preferences and autoscaling is applied. Everything else belongs in the constructor.
Update to Windows 8 or later, they have this wow64 problem solved.
In my experience, I only see this issue when I'm running with a debugger attached. The application behaves the same when run standalone: the exception is not swallowed.
With the introduction of KB976038, you can make this work as you'd expect again. I never installed the hotfix, so I'm assuming it came as part of Win7 SP1.
This was mentioned in this post:
The case of the disappearing OnLoad exception – user-mode callback exceptions in x64
Here's some code that will enable the hotfix:
public static class Kernel32
{
public const uint PROCESS_CALLBACK_FILTER_ENABLED = 0x1;
[DllImport("Kernel32.dll")]
public static extern bool SetProcessUserModeExceptionPolicy(UInt32 dwFlags);
[DllImport("Kernel32.dll")]
public static extern bool GetProcessUserModeExceptionPolicy(out UInt32 lpFlags);
public static void DisableUMCallbackFilter() {
uint flags;
GetProcessUserModeExceptionPolicy(out flags);
flags &= ~PROCESS_CALLBACK_FILTER_ENABLED;
SetProcessUserModeExceptionPolicy(flags);
}
}
Call it at the beginning of your application:
[STAThread]
static void Main()
{
Kernel32.DisableUMCallbackFilter();
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
I've confirmed (with the the simple example shown below) that this works, just as you'd expect.
protected override void OnLoad(EventArgs e) {
throw new Exception("BOOM"); // This will now get caught.
}
So, what I don't understand, is why it was previously impossible for the debugger to handle crossing kernel-mode stack frames, but with this hotfix, they somehow figured it out.
As Hans mentions, compile the application and run the exe without a debugger attached.
For me the problem was changing a Class property name that a BindingSource control was bound to. Running without the IDE I was able to see the error:
Cannot bind to the property or column SendWithoutProofReading on the
DataSource. Parameter name: dataMember
Fixing the BindingSource control to bind to the updated property name resolved the problem:
I'm using WPF and ran into this same problem. I had tried Hans 1-3 suggestions already, but didn't like them because studio wouldn't stop at where the error was (so I couldn't view my variables and see what was the problem).
So I tried Hans' 4th suggestion. I was suprised at how much of my code could be moved to the MainWindow constructor without any issue. Not sure why I got in the habit of putting so much logic in the Load event, but apparently much of it can be done in the ctor.
However, this had the same problem as 1-3. Errors that occur during the ctor for WPF get wrapped into a generic Xaml exception. (an inner exception has the real error, but again I wanted studio to just break at the actual trouble spot).
What ended up working for me was to create a thread, sleep 50ms, dispatch back to main thread and do what I need...
void Window_Loaded(object sender, RoutedEventArgs e)
{
new Thread(() =>
{
Thread.Sleep(50);
CrossThread(() => { OnWindowLoaded(); });
}).Start();
}
void CrossThread(Action a)
{
this.Dispatcher.BeginInvoke(a);
}
void OnWindowLoaded()
{
...do my thing...
This way studio would break right where an uncaught exception occurs.
A simple work-around could be if you can move your init code to another event like as Form_Shown which called later than Form_Load, and use a flag to run startup code at first form shown:
bool firstLoad = true; //flag to detect first form_shown
private void Form1_Load(object sender, EventArgs e)
{
//firstLoad = true;
//dowork(); //not execute initialization code here (postpone it to form_shown)
}
private void Form1_Shown(object sender, EventArgs e)
{
if (firstLoad) //simulate Form-Load
{
firstLoad = false;
dowork();
}
}
void dowork()
{
var f = File.OpenRead(#"D:\NoSuchFile756.123"); //this cause an exception!
}
I use the following code to check if a Single Instance of the CustomBA is already running in the Run block of the CustomBA.
When the user starts the "setup.exe" (CustomBA) by double clicking it the code below returns true which is the expected behaviour.
However when the user right clicks and starts it as administrator the code returns false. Why is that?
private bool IsSingleInstanceOfSetupRunning()
{
bool result = true;
Process currentProcess = Process.GetCurrentProcess();
if (Process.GetProcessesByName(currentProcess.ProcessName).Length > 1)
{
result = false;
}
return result;
}
It appears that the WiX Engine detects that the process is running as admin and spins up the secondary process used for actually installing the MSIs. So there really are two processes running with the same name.
You can see the same behavior with the non-admin process once your CustomBA code calls Engine.Apply(). This is typically when the user sees a UAC prompt as the Engine spins up the second, elevated process to handle the actual MSI installs.
Since the main process is already running as admin, and no UAC prompting will occur by spinning up the second process, the Engine goes ahead and starts it immediately instead of waiting for the call to Engine.Apply().
Also note: if you're performing a Major Upgrade, the uninstall of the prior version will be run (in silent mode) during the upgrade, which would result in additional processes. You need to make sure you allow the uninstall process to run even if there is another process already running (your upgrade process).
One approach would be to use a mutex to do the checking, but only when running in DisplayMode Display.Full:
if (DisplayMode == Display.Full)
{
bool mutexCreated = false;
mutex = new Mutex(true, #"My Installer F1096BB9-CFDF-4AD1-91D8-9AA8805784A8", out mutexCreated);
if (!mutexCreated)
{
MessageBox.Show("Another instance of the installer is already running. You may only run one at a time.",
"Installer already running", MessageBoxButton.OK,
MessageBoxImage.Warning);
Log("Installer already running");
Exit(ActionResult.NotExecuted);
}
}
public void Exit(ActionResult actionResult)
{
if (mutex != null)
{
mutex.Close();
mutex = null;
}
Log(string.Format("Exiting with code {0}", actionResult));
Engine.Quit((int) actionResult);
}
I'm getting this error when I deploy a VB.NET application and for the life of me I cannot figure out why.
I do not get this error when I run the app from the IDE and the test machine I am deploying it to has a similar configuration to the dev machine...Windows 7 & .NET 3.51 SP1 and 4.0.
The app bombs out when the main form is loaded after logging in. I've narrowed it down to the main form because if I load another form from login and then open the main form, this happens.
Linked below is a screenshot of the stack trace.
Any ideas? I'm really lost here.
Thanks.
I do not see a way for ShapeCollection.Dispose() to throw that exception. Although it is manipulating a List<> that can indeed throw that exception, the code should not trigger it:
private void Dispose(bool disposing)
{
if (!this.m_Disposed && disposing)
{
for (int i = this.m_Shapes.Count - 1; i >= 0; i--)
{
this.m_Shapes[i].Dispose();
}
this.m_Shapes.Clear();
this.m_Shapes = null;
}
this.m_Disposed = true;
}
Well, this is from the PowerPacks version that I have. There have been a couple of versions of it floating around, it used to be distributed separately. Make sure you didn't accidentally deploy an old version.
IN Visual Studio when I try to start a windows service project it tells me I cant because I have to use "NET Start" and so forth.
I remember in VS 2003 that when I pressed play it started the service and stop stopped it. Is there any way that when I press play or start for that windows service project I can have this same functionality.
What I currently do is install them using installutil and I put a pre-processor command with System.Diagnostics.Debug.Launch() when I have a compilation variable defined and when I use the service manager it shows me the window to select the debugger. Still this method is somewhat cumbersome.
For anyone else reading this, remember to try to debug ONE thread at a time.
I usually allow for a command line switch that I can pass to my service using the command line argument settings in the IDE. When this switch is on I can run my service as a regular app. The only issue here is that you need to remember that services usually run under accounts with restricted permissions, so debugging as an app in your user context may behave differently when accessing secured resources. Here is example code:
static void Main()
{
if (IsDebugMode())
{
MyService svc = new MyService();
svc.DebugStart();
bool bContinue = true;
MSG msg = new MSG();
// process the message loop so that any Windows messages related to
// COM or hidden windows get processed.
while (bContinue && GetMessage(out msg, IntPtr.Zero, 0, 0) > 0)
{
if (msg.message != WM_QUIT)
DispatchMessage(ref msg);
else
bContinue = false;
}
}
else
{
ServiceBase.Run(new MyService());
}
}
public void DebugStart()
{
this.OnStart(null);
}
static bool IsDebugMode()
{
return (System.Environment.CommandLine.IndexOf("debug") > -1);
}